What “production-grade” means here.

Test and Live, like software

Every flow keeps a mutable draft and immutable saved versions. You run a flow in a separate Test environment and watch each node execute before anything reaches customers; only then do you promote a saved checkpoint to Live, the way an engineering team ships a release. A saved version does not change under you — promotion points Live at a specific, frozen version, so what you approved is exactly what runs.

Guardrails that stop a run before it overspends

Settlement defaults to dry-run: a newly launched agent moves no real USDC until its creator explicitly switches it live. Beyond that, spend is bounded on two axes — every run enforces a per-run cost ceiling checked before each cost-bearing node, and each agent has a per-agent daily cap backed by durable run history, not just an in-memory counter. When a node on the main path fails, the engine halts its branch instead of charging for the downstream work that would have depended on it. Every run writes a per-step USDC cost ledger you can audit after the fact.

What the health checks probe

The status page reads three live checks each time it is refreshed, and an hourly job records each result so availability can be measured over time:

• Studio API — a trivial, non-mutating query against the datastore. If this fails, the studio cannot serve, and the overall status is a major outage.
• Model gateway — a reachability check against the LLM gateway. No API key is sent, so nothing is spent and no secret is exposed.
• x402 settlement — a reachability check against the configured x402 facilitator. It never calls the paid verify or settle paths, so probing costs nothing and moves no money.

The gateway and the facilitator are treated as non-core: if one is unreachable the status reads degraded, not down, because the studio itself is still up. Probes surface only reachability and latency — never an upstream error string, wallet address, or credential.

The hourly-resolution caveat

The recorder runs on the existing hourly cron. That resolution is honest but coarse: a shorter outage can fall entirely within one recorded hour and never register as a separate down check. We show the check interval next to every availability figure precisely so the number is never read as finer-grained than it is.

Why there is no uptime percentage yet

A defensible “99.9%”-style claim needs two things at once: roughly ninety continuous days of recorded checks, and sub-five-minute resolution so short outages cannot hide. Today's hourly cron gives only the first ingredient over time, not the second. Until both hold, the status page publishes no headline uptime percentage. It shows the real short-window figure paired with its window and check interval, or, before a window is meaningfully filled, “Measuring since” a date with the count of checks recorded so far. We would rather show you the data as it accumulates than invent a number to fill the gap.

Run volume, not a graded success rate

The status page reports launched-agent activity as throughput — completed runs, median run time, and how many agents are live — never as a success rate. A single raw success rate mixes platform failures with user-caused ones: a broken draft or a bad prompt is a user outcome, not an outage, and folding the two together would either flatter or unfairly punish the platform. Counts and durations stay honest without that ambiguity.

See it live

The status page renders the current checks and every measured window. Monitors and agents can poll /api/health (200 when up, 503 on a major outage) or /status.json for the same figures as JSON.