| Participant | Uptime | Downtime | p50 | |
|---|---|---|---|---|
| Schedulerours | 4.19% | 16349 missed | — | |
| 100% | — | 153ms | ||
| 100% | — | 821ms | ||
| 99.85% | 1 min | 257ms | ||
| 99.85% | 1 min | 459ms | ||
| 99.85% | 1 min | 1.09s | ||
| 99.85% | 1 min | 1.27s | ||
| 99.71% | 2 min | 905ms | ||
| 99.70% | 2 min | 5.05s | ||
| 99.57% | 3 min | 299ms | ||
| 99.57% | 3 min | 511ms | ||
| 99.57% | 3 min | 1.66s | ||
| 99.43% | 4 min | 239ms | ||
| 99.29% | 5 min | 3.04s | ||
| 99.29% | 5 min | 3.29s | ||
| 99.15% | 6 min | 418ms | ||
| 99.00% | 7 min | 447ms | ||
| 98.86% | 8 min | 1.76s | ||
| 98.72% | 9 min | 1.02s | ||
| 98.58% | 10 min | 902ms | ||
| 98.44% | 11 min | 498ms | ||
| 98.44% | 11 min | 692ms | ||
| 98.30% | 12 min | 424ms | ||
| 98.30% | 12 min | 8.27s | ||
| 97.87% | 15 min | 2.25s | ||
| 97.73% | 16 min | 781ms | ||
| 97.45% | 18 min | 890ms | ||
| 97.45% | 18 min | 4.40s | ||
| 97.31% | 19 min | 282ms | ||
| 96.74% | 23 min | 2.23s | ||
| 96.32% | 26 min | 739ms | ||
| 95.92% | 29 min | 192ms | ||
| 76.00% | 6 min | 43.66s | ||
| 40.74% | 16 min | 27.58s | ||
| 0.00% | 5 min | — | ||
| 0.00% | 5 min | — | ||
| 0.00% | 5 min | — | ||
| 0.00% | 5 min | — |
Hover a cell for its numbers. Click a participant cell to open their checks for that day.
- Down
Tenki
Wed, Nov 4 08:28 UTC → Wed, Nov 4 08:31 UTC · 4 min · 3 failedstep_timeout - Down
Sail
Wed, Nov 4 04:51 UTC → Wed, Nov 4 04:54 UTC · 4 min · 3 failedstep_timeout
What went wrong (8 errors)
- 129×reliability_install_failed
- 106×reliability_run_failed
- 57×reliability_create_failed
- 12×step_timeout
- 10×participant failed
- 6×reliability_verify_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.