Reliability Benchmarks

Our reliability benchmark creates a sandbox, runs a workload, and destroys it every minute to test the uptime reliability of sandbox providers. All times are UTC.

All passedBlipsDownMissed (scheduler)Pending
ParticipantUptimeDowntimep50
Schedulerours99.15%3 missed—
Promigence100%—153ms
Miosa100%—191ms
Archil100%—273ms
CreateOS100%—292ms
Daytona100%—408ms
Superserve100%—440ms
Blaxel100%—491ms
Beam100%—513ms
Novita100%—832ms
Upstash100%—901ms
Mosaic100%—902ms
Tenki100%—1.01s
Vercel100%—1.74s
Namespace100%—2.21s
Tensorlake100%—2.25s
Sandbox0100%—3.06s
Run Cloud100%—4.38s
Isorun99.71%1 min234ms
Gravixlayer99.71%1 min256ms
Arker99.71%1 min413ms
Buddy99.71%1 min456ms
Cloudflare99.71%1 min689ms
Cloud Run99.71%1 min730ms
Modal99.71%1 min760ms
sfcompute99.71%1 min1.08s
Freestyle99.71%1 min1.26s
E2B99.71%1 min1.78s
Railway99.71%1 min5.04s
CodeSandbox99.71%1 min8.24s
Sprites99.43%2 min875ms
Sail99.14%3 min3.27s

Hover a cell for its numbers. Click a participant cell to open their checks for that day.

  • DownSail
    Wed, Nov 4 04:51 UTC → Wed, Nov 4 04:54 UTC · 4 min · 3 failed
    step_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.

On this leaderboard? Your next public run is benchmark Friday — know your number every day.Get stealth benchmarks →