What it answers
“Why has nothing happened?” Loop health answers that from records rather than guesses. For each workspace and each day it shows:- Readings per engine: how many succeeded and how many failed.
- Scheduled automation outcomes: each automation that fired, was skipped (with the reason), or failed.
- Detection findings raised by the hourly detection pass.
- Work produced: items filed for your approval or review.
- Approvals pending: how many items wait on a person.
- Pull requests opened.
- Re-reads due: before-and-after re-reads scheduled for that day.
get_loop_health over MCP, and as GET /v1/loop-health over the REST API.
The three statuses
A workspace is blocked when any of these is true:
- the credit balance is spent;
- no reading succeeded in two days;
- nothing is scheduled and detection is off;
- every scheduled run failed;
- the scheduler stopped.
The org home at /clients currently shows a simpler status per workspace, derived from its automations: blocked when there is no scheduled automation, all of them are paused, or credits are used up; idle when an automation is scheduled but has never run, or has not run in 48 hours. It will read loop health instead once that is wired in.
Why a scheduled run was skipped
A skipped run is recorded, grouped with a count, instead of disappearing. Each skip carries one of these reasons:Credits stop runs, not readings
A spent credit balance stops scheduled automation runs. It does not stop readings: the daily answers to your tracked prompts run on your plan’s monthly response budget, not on credits. A blocked workspace with no credits still gets its numbers; what stops is the work built on them. Loop health itself costs nothing and answers on a spent balance.Over the API
Shell
Response
days takes 1 to 30 and defaults to 7. The dashboard reads the same data from GET /v2/projects/{id}/loop-health.