| Participant | Uptime | Downtime | p50 | |
|---|---|---|---|---|
| Schedulerours | 3.84% | 16349 missed | — | |
| 100% | — | 154ms | ||
| 100% | — | 822ms | ||
| 99.83% | 1 min | 256ms | ||
| 99.83% | 1 min | 459ms | ||
| 99.83% | 1 min | 1.09s | ||
| 99.83% | 1 min | 1.27s | ||
| 99.68% | 2 min | 907ms | ||
| 99.67% | 2 min | 5.05s | ||
| 99.53% | 3 min | 302ms | ||
| 99.53% | 3 min | 513ms | ||
| 99.53% | 3 min | 1.69s | ||
| 99.37% | 4 min | 241ms | ||
| 99.22% | 5 min | 3.05s | ||
| 99.22% | 5 min | 3.31s | ||
| 99.06% | 6 min | 420ms | ||
| 98.91% | 7 min | 449ms | ||
| 98.75% | 8 min | 1.76s | ||
| 98.60% | 9 min | 1.02s | ||
| 98.44% | 10 min | 902ms | ||
| 98.29% | 11 min | 500ms | ||
| 98.29% | 11 min | 704ms | ||
| 98.13% | 12 min | 424ms | ||
| 98.13% | 12 min | 8.27s | ||
| 97.67% | 15 min | 2.25s | ||
| 97.51% | 16 min | 778ms | ||
| 97.20% | 18 min | 912ms | ||
| 97.20% | 18 min | 4.40s | ||
| 97.04% | 19 min | 284ms | ||
| 96.42% | 23 min | 2.23s | ||
| 95.96% | 26 min | 741ms | ||
| 95.53% | 29 min | 192ms | ||
| 76.00% | 6 min | 43.66s | ||
| 40.74% | 16 min | 27.58s | ||
| 0.00% | 5 min | — | ||
  Lightning AI | 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.
Incidents
No ongoing incidents in this window. Incidents are stretches of 3+ consecutive checks that did not pass.
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.