| Participant | Uptime | Downtime | p50 | |
|---|---|---|---|---|
| Schedulerours | 8.65% | 7207 missed | — | |
| 100% | — | 153ms | ||
| 100% | — | 192ms | ||
| 100% | — | 281ms | ||
| 100% | — | 297ms | ||
| 100% | — | 415ms | ||
| 100% | — | 445ms | ||
| 100% | — | 494ms | ||
| 100% | — | 509ms | ||
| 100% | — | 821ms | ||
| 100% | — | 885ms | ||
| 100% | — | 902ms | ||
| 100% | — | 1.76s | ||
| 100% | — | 2.22s | ||
| 100% | — | 2.25s | ||
| 100% | — | 4.39s | ||
| 99.85% | 1 min | 237ms | ||
| 99.85% | 1 min | 257ms | ||
| 99.85% | 1 min | 422ms | ||
| 99.85% | 1 min | 459ms | ||
| 99.85% | 1 min | 685ms | ||
| 99.85% | 1 min | 739ms | ||
| 99.85% | 1 min | 779ms | ||
| 99.85% | 1 min | 1.09s | ||
| 99.85% | 1 min | 1.27s | ||
| 99.85% | 1 min | 1.64s | ||
| 99.85% | 1 min | 3.03s | ||
| 99.85% | 1 min | 8.27s | ||
| 99.70% | 2 min | 871ms | ||
| 99.70% | 2 min | 5.05s | ||
| 99.56% | 3 min | 3.27s | ||
| 99.12% | 6 min | 1.00s |
Hover a cell for its numbers. Click a participant cell to open their checks for that day.
- MissedAll participantsTue, Nov 3 22:33 UTC → Tue, Nov 3 22:36 UTC · 4 min · 0 failed, 3 missed
- MissedAll participantsThu, Oct 29 00:00 UTC → Tue, Nov 3 00:00 UTC · 5 d 0 h · 0 failed, 7200 missed
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.