Service status

Last 24h · managed-proxy/direct production requests only. Customer-proxy, sandbox and historical records with unknown proxy attribution are excluded. Success rate is solved ÷ (solved + failed); pending requests are excluded. Latency is recorded successful solve time, not end-to-end wall-clock time. Performance reports refresh every 5 minutes. The window uses request creation time; today's homepage count includes successful requests created since midnight UTC. Recorded solve time excludes queue wait, earlier retries and network time. A successful provider result does not confirm acceptance by the target.

Provider and gate health, circuit states and observation times are operational signals. Attempt counts and timings are omitted from public metrics because operational telemetry mixes customer-proxy and managed/direct traffic.

Health is sampled approximately every 60 seconds; this page refreshes every 30 seconds. A first failed check is flagged for attention. Consecutive failed checks roughly one sampling interval apart confirm a disruption. Missing recent checks show “No recent data”.

Each bar represents one UTC day. Its colored portion reflects the fraction of unhealthy checks, with a small minimum mark so brief problems stay visible. Five or more failed checks are marked red; shorter interruptions are amber. Choose an exact date for counts and coverage, or use the arrow keys and Home / End on the bars.

The 30/90-day selector changes the visible history; the 90-day healthy-check percentage always covers the full report. It is the percentage of recorded checks that were healthy, not an exact measurement of downtime. Missing days stay gray. Days with checks but less than 90% of expected samples have a bottom mark for partial coverage; today’s coverage is measured only up to the snapshot time. Monitoring covers service dependencies and solver availability; it is not an external end-to-end guarantee.