| Participant | Uptime | Downtime | p50 | |
|---|---|---|---|---|
| Schedulerours | 7.92% | 7207 missed | — | |
| 100% | — | 154ms | ||
| 100% | — | 192ms | ||
| 100% | — | 283ms | ||
| 100% | — | 299ms | ||
| 100% | — | 416ms | ||
| 100% | — | 447ms | ||
| 100% | — | 496ms | ||
| 100% | — | 511ms | ||
| 100% | — | 822ms | ||
| 100% | — | 904ms | ||
| 100% | — | 907ms | ||
| 100% | — | 1.76s | ||
| 100% | — | 2.23s | ||
| 100% | — | 2.25s | ||
| 100% | — | 4.40s | ||
| 99.83% | 1 min | 239ms | ||
| 99.83% | 1 min | 256ms | ||
| 99.83% | 1 min | 423ms | ||
| 99.83% | 1 min | 459ms | ||
| 99.83% | 1 min | 696ms | ||
| 99.83% | 1 min | 741ms | ||
| 99.83% | 1 min | 773ms | ||
| 99.83% | 1 min | 1.09s | ||
| 99.83% | 1 min | 1.27s | ||
| 99.83% | 1 min | 1.68s | ||
| 99.83% | 1 min | 3.04s | ||
| 99.83% | 1 min | 8.26s | ||
| 99.67% | 2 min | 871ms | ||
| 99.67% | 2 min | 5.05s | ||
| 99.51% | 3 min | 3.28s | ||
| 99.03% | 6 min | 1.02s |
Hover a cell for its numbers. Click a participant cell to open their checks for that day.
Incidents
No ongoing incidents in this window. Incidents are stretches of 3+ consecutive checks that did not pass.
What went wrong (4 errors)
- 12×step_timeout
- 10×participant failed
- 2×probe_failed
- 1×participant failed before reporting results
How it works: a ComputeSDK Actions run fires on schedule and, for each provider, creates a fresh sandbox through that provider’s ComputeSDK adapter — the same create path our TTI and DAX benchmarks use. Inside the sandbox it writes a 1 MiB file of random data, SHA-256 hashes it twice, requires the digests to match, deletes the file, and destroys the sandbox. The check passes only if the full create → probe → destroy loop succeeds in time; runs that fail to dispatch count as scheduler misses, not provider downtime.
Need a provider’s uptime on demand? Sign up for a free ComputeSDK account and query any provider’s status through the API, CLI, or MCP.