After you launch

Findings are graded by blast radius into four tiers, and the dial decides how far up that grade the loop may act without you. The grading is the part worth learning; the dial is just a pointer into it.

The loop runs at a one-minute cadence on every plan including Free, with no per-window cap and no monthly budget. That is possible because it runs no language model — it is probes and typed actions, so it costs no AI credits and there is nothing to ration. A backend that stops repairing itself when you hit a quota is the failure mode this feature exists to remove, so it is not a paywall on any plan. Plans differ on capacity — projects, users, storage, AI credits — not on whether the loop keeps working.

There is one real bound worth knowing, and it is not a pricing lever. A project enters each pass only if it shows a sign of life in the last 30 days: end-user traffic, a governed change, a conversation with the brain, or simply having been created or modified recently. A project with tables but no signal for 30 days stops being swept until one arrives.

That gate is deliberately generous — traffic alone qualifies, so a live backend nobody has talked about in a month keeps being healed. But it does mean a genuinely dormant project is not being checked, and it is more honest to say so than to imply a backend with no users and no changes is under continuous watch.

One other bound exists and it is a safety limit, not a quota: a rolling ceiling of 500 autonomous data-mutating actions per hour. It is set far above any real workload — a project needing 500 repairs in an hour is broken, not busy — and exists so a flapping detector that "fixes" the same gap every minute cannot rewrite real user data indefinitely.

1. Monitor

   Telemetry from the running backend

   Request logs, latency, error rates, and schema state.

2. Analyze

   Probes look for specific conditions

   Schema drift, missing indexes, slow queries, RLS gaps, broken triggers, stuck deployments. A probe that cannot run reports UNCHECKED rather than passing.

3. Plan

   Findings become typed fix actions

   The same vocabulary your agent uses. A finding with no safe inverse is not proposed as automatic.

4. Execute

   The safe band is applied; the rest waits

   Additive, snapshotted, reversible changes go through. Anything touching auth, credentials, or data destruction lands in the review queue.

5. Report

   A receipt, not a checkmark

   What was detected, what changed, how it was verified — in the Autonomy tab and the project journal.

Anything the loop will not apply lands in the Review Queue — the "Waiting on you" section of the Autonomy tab — with approve and reject, and the same receipt. Your agent can poll an escalated destructive operation with `check_approval` rather than sitting on an open call.

Changes the loop made on its own appear in an applied-changes panel with an Undo. The button is drawn only when the engine will actually honour it: eligibility comes from the same predicate the revert path gates on, so a fix whose pre-fix snapshot failed to capture shows the reason instead of a button that would error on click.

Undoing a row-level security fix is treated differently, because it removes a protection rather than restoring a prior state. It takes a second explicit confirmation, enforced by the server independently of the UI.

Three different mechanisms get called "rollback" and it is worth keeping them apart. Undo on the applied-changes panel reverts an autonomous fix from its pre-fix snapshot. Schema versions are separate: every schema-mutating action snapshots first, and you can list those versions and roll back to one. Deployment rollback is a third thing, and it is plan-gated — Free keeps no deployment history, so it is not available there. Check the pricing page for where your plan sits.

Everything is computed from one request-log source of truth, so the dashboard and the loop cannot disagree about what happened. You get latency percentiles (p50/p95/p99), error rate, per-endpoint health, slow-query traces, anomaly detection, and incident history.

Health findings surface where you can act on them — the dashboard's clear-up panel and the Autonomy tab — and deliberately not on the monitoring views themselves, which stay neutral. Monitoring is for reading what happened; the queue is for deciding what to do.

Going live runs a readiness scorecard first and reports blockers and warnings separately — blockers stop the deploy, warnings do not. Then it asks for an explicit typed confirmation before anything becomes publicly callable.