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
- 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.
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
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 daily cap backed by durable run history. Optional per-call sales start switched off, so no caller payment moves until you turn them on. 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 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 read-only 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 (the optional per-call rail): 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, payout address, or credential.
Hourly check resolution
The recorder saves a check every hour, building a continuous, dated record of service health. Every availability figure carries its check interval and measurement window, so you know exactly what each number measures.
Read availability with its measurement window
The status page shows the measured availability for each window, paired with that window and its check interval. While a window fills, it shows “Measuring since” a date with the count of checks recorded so far. The status page adds a headline uptime percentage once ninety days of checks at sub-five-minute resolution are recorded. Every figure comes straight from recorded checks, so it holds up when a client asks.
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. Open any run record to see every step of a flow and its prompts, and use the health checks to follow the platform itself.
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 .