| Participant | Uptime | Downtime | p50 | |
|---|---|---|---|---|
| Schedulerours | 99.39% | 3 missed | — | |
| 100% | — | 146ms | ||
| 100% | — | 187ms | ||
| 100% | — | 268ms | ||
| 100% | — | 287ms | ||
| 100% | — | 402ms | ||
| 100% | — | 435ms | ||
| 100% | — | 481ms | ||
| 100% | — | 508ms | ||
| 100% | — | 816ms | ||
| 100% | — | 869ms | ||
| 100% | — | 895ms | ||
| 100% | — | 1.74s | ||
| 100% | — | 2.19s | ||
| 100% | — | 2.24s | ||
| 100% | — | 4.36s | ||
| 99.79% | 1 min | 229ms | ||
| 99.79% | 1 min | 252ms | ||
| 99.79% | 1 min | 411ms | ||
| 99.79% | 1 min | 452ms | ||
| 99.79% | 1 min | 675ms | ||
| 99.79% | 1 min | 723ms | ||
| 99.79% | 1 min | 761ms | ||
| 99.79% | 1 min | 1.06s | ||
| 99.79% | 1 min | 1.24s | ||
| 99.79% | 1 min | 1.74s | ||
| 99.79% | 1 min | 3.02s | ||
| 99.79% | 1 min | 8.25s | ||
| 99.59% | 2 min | 855ms | ||
| 99.59% | 2 min | 5.03s | ||
| 99.39% | 3 min | 977ms | ||
| 99.39% | 3 min | 3.23s |
Hover a cell for its numbers. Click a participant cell to open their checks for that day.
- Down
Sail
Wed, Nov 4 04:51 UTC → Wed, Nov 4 04:54 UTC · 4 min · 3 failedstep_timeout
What went wrong (4 errors)
- 10×participant failed
- 9×step_timeout
- 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.