Ship with control. Monitor every run.
Test a saved version, choose when it goes Live, and set spending caps before it runs. Use the live status page to follow service health, check intervals, and recorded activity.
- What you'll do
- See the safeguards built into every run, and exactly what the status page probes and how often.
- What you'll have
- A release and monitoring plan grounded in version history, spending caps, and dated health checks.
Quick definitions: dry run and x402
- Dry run
- A test run that executes your flow's logic for real but stubs every step that would cost money or reach an outside system, so nothing is spent.
- x402
- An open payment protocol built on HTTP status 402 (Payment Required). The server answers an unpaid request with its price, the caller's wallet signs a payment and retries, and the work runs once the payment settles.
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.
Hourly check resolution
The recorder saves a check every hour. Each availability figure includes its check interval and measurement window so you can interpret it correctly. Outages between hourly checks may go unrecorded.
Read availability with its measurement window
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.
Track activity and execution time
The status page reports launched-agent activity as throughput (completed runs, median run time, and how many agents are live), separately from service availability. These counts and durations measure activity rather than a success rate; individual run records help you investigate flow and prompt errors, while health checks track platform availability.
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.
Last updated .