| Participant | Uptime | Downtime | p50 | |
|---|---|---|---|---|
| Schedulerours | 99.15% | 3 missed | — | |
| 100% | — | 153ms | ||
| 100% | — | 191ms | ||
| 100% | — | 273ms | ||
| 100% | — | 292ms | ||
| 100% | — | 408ms | ||
| 100% | — | 440ms | ||
| 100% | — | 491ms | ||
| 100% | — | 513ms | ||
| 100% | — | 832ms | ||
| 100% | — | 901ms | ||
| 100% | — | 902ms | ||
| 100% | — | 1.01s | ||
| 100% | — | 1.74s | ||
| 100% | — | 2.21s | ||
| 100% | — | 2.25s | ||
| 100% | — | 3.06s | ||
| 100% | — | 4.38s | ||
| 99.71% | 1 min | 234ms | ||
| 99.71% | 1 min | 256ms | ||
| 99.71% | 1 min | 413ms | ||
| 99.71% | 1 min | 456ms | ||
| 99.71% | 1 min | 689ms | ||
| 99.71% | 1 min | 730ms | ||
| 99.71% | 1 min | 760ms | ||
| 99.71% | 1 min | 1.08s | ||
| 99.71% | 1 min | 1.26s | ||
| 99.71% | 1 min | 1.78s | ||
| 99.71% | 1 min | 5.04s | ||
| 99.71% | 1 min | 8.24s | ||
| 99.43% | 2 min | 875ms | ||
| 99.14% | 3 min | 3.27s |
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
- 5×step_timeout
- 1×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.