Loop health

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. A finding held as noise is not counted.
Work produced: items filed for your approval or review.
Approvals pending: how many items wait on a person.
Pull requests opened.
Checks due (rereads_due in the API): before-and-after checks whose after-window has closed and that the next nightly pass runs for the first time. A check still inside its window is being measured and is not counted. A check that failed is not counted as due either: each failed try is a line of its own, Measuring shipped changes, and the check is tried again until it has a verdict or stops with a stated reason.

Each count is read once for its date. The days are listed side by side, but they are not a trend and nothing in the report compares one day with another. In the app, New chat shows a card above Needs you whenever something is holding your work: what it is, and the one thing to do about it when it is yours to fix. The same words reach you by email at most once a day (see When a block is yours). Nothing about a block waits on anybody at Attensira. The brief verb carries the status and the first reason over MCP; the full day-by-day report is get_loop_health, which left the MCP tool list on 2026-10-19 and still answers by name, and GET /v1/loop-health over the REST API.

The three statuses

Status	Meaning
Working	Work was produced, or a pull request opened, in the last two days
Idle	Nothing is blocked, and nothing was produced. A quiet loop, not a broken one
Blocked	Something stops the loop. The reasons say which

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;
agent work or answer checks are paused while we fix a problem on our side (see When something on our side stops).

Every status comes with its reasons as sentences you can act on, such as “The credit balance is spent, so scheduled automation runs are refused. Top up to restart the loop.” or “‘Daily win plan’ is paused.” Reasons also carry notes that do not block the loop, such as how many pieces of work wait for your approval.

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:

Reason	What it means
`no_credits`	The credit balance was spent when the run was due. See Credits
`manual_trigger`	The automation only runs when started by hand (When I ask), so nothing was scheduled
`parked_on_ask`	The previous run is waiting on an answer from you; the scheduled fire handed that run back instead of starting another
`flag_disabled`	Detection is off for this workspace, so a lost citation or a competitor change does not start work on its own
`retired`	The product paused the automation on its own (see `retired_reason` on the automation). Resume it to put it back on the schedule
`paused`	Somebody paused it
`cap_reached`	A change cap was reached; the changes over it wait for you to approve them by hand
`in_flight`	A run of the same automation was still in progress, so a second was not started
`vendor_incident`	The run was paused while we fix a problem on our side (see When something on our side stops). Not a failure: the automation runs once on its own when the problem is fixed. See Paused runs catch up automatically
`not_worth_run`	Every event in the batch was a competitor’s change that a decision judged not worth a run of this event automation, so nothing started

Markets add two lines of their own, named after the market or language rather than an automation. The first is recorded as a skipped run, the second as a failed one:

Reason	What it means
`market_allowance_reached`	Readings in DE were skipped: this month’s response allowance is held for your primary market, which keeps reading. They resume when the allowance resets
`translation_failed`	Translations into de could not be made, so readings in that market language wait and are retried on the next pass. They are never asked in the original language instead

When something on our side stops

When something Attensira runs on stops working for us, every workspace that depends on it says so in one sentence, first among the reasons:

Agent work is paused while we fix a problem on our side. Next try at 16:10. Nothing for you to do.

The sentence starts with the work that waits: Agent work, Answer checks, Google rank tracking, Page checks, Emails from us, or Some scheduled work. The time of the next try is in your workspace’s time zone; a workspace with no time zone set gets the sentence without it. When something is failing without having stopped, after two failed tries in a row, the sentence says the work may be late instead, as a note: “Page checks may run late while we fix a problem on our side. Next try at 16:10. Nothing for you to do.”

It is ours to fix, never yours. It does not touch your credits or your connections.
We try again every 10 minutes. A try that works ends the pause on its own; nobody marks it fixed.
Agent work or answer checks being paused makes the workspace Blocked. Google rank tracking, page checks or our email being paused is a note, because the rest of the work carries on.
The sentence never says whose system failed and never states a balance.
A workspace blocked by one carries "owner": "product": it is ours to act on. A workspace blocked for a reason only you can fix (credits, a cap, nothing scheduled) carries "owner": "customer". owner is absent when the workspace is not blocked.

A run that such a pause stopped, before it started or partway through, is recorded as skipped with the reason vendor_incident, not as failed, and files nothing in your Inbox. When the problem is fixed, each such automation runs once on its own; see Paused runs catch up automatically. The claim check and Google rank tracking wait and catch up the same way. See also Troubleshooting.

When a block is yours

When the loop is blocked for a reason only you can clear, or a connection needs reconnecting, you are told what it is and given one action:

What is holding the work	The action
A connection needs reconnecting (even when the loop is otherwise working)	Reconnect, which opens that connection’s page
The credit balance is spent	Top up credits
A spending limit you set was reached	Review the limit
Nothing is scheduled and detection is off	Review automations
Anything else that is yours	Review, which opens the Inbox

When more than one applies, a broken connection comes first, then the balance. The card on New chat shows it as soon as the loop is blocked. The email (the Attention category of your notifications) goes out once the block has lasted 12 hours, at most once a day, and says that nothing was changed while the work waited. A block that is ours says so (“Work is paused on our side”) and asks nothing of you: it ends on its own when it is fixed. GET /v1/projects/{id}/loop-health, the dashboard’s read, carries the action as fix, absent when nothing is yours to do:

"fix": {
  "code": "no_credits",
  "title": "Work on this workspace is paused: the credit balance is spent",
  "body": "Scheduled runs are refused until there is a balance again. Nothing already recorded is lost, and work picks up on its own once you top up.",
  "label": "Top up credits",
  "path": "/settings/billing?project=<workspace id>"
}

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

curl "https://api.attensira.com/v1/loop-health?days=7" \
  -H "Authorization: Bearer atn_live_<your key>"

Response

{
  "status": "blocked",
  "owner": "customer",
  "reasons": ["The credit balance is spent, so scheduled automation runs are refused. Top up to restart the loop. (Readings run on the plan's response budget, not credits.)"],
  "days": [
    {
      "date": "2026-09-22",
      "readings": { "chatgpt": { "ok": 40, "failed": 1 }, "perplexity": { "ok": 41, "failed": 0 } },
      "runs": [
        { "automation_id": "aut_71cd", "name": "Daily win plan", "status": "skipped", "reason": "no_credits", "count": 1, "at": "2026-09-22T06:00:00Z" }
      ],
      "findings": 2,
      "work_produced": 0,
      "approvals_pending": 3,
      "prs_opened": 0,
      "rereads_due": 1
    }
  ]
}

days takes 1 to 30 and defaults to 7. The dashboard reads the same data from GET /v1/projects/{id}/loop-health.

Get started

The app

What you track

Reading the numbers

Pages and AI traffic

The agent

MCP

REST API

Agencies and client reporting

Account

Reference

What it answers

The three statuses

Why a scheduled run was skipped

When something on our side stops

When a block is yours

Credits stop runs, not readings

Over the API

​What it answers

​The three statuses

​Why a scheduled run was skipped

​When something on our side stops

​When a block is yours

​Credits stop runs, not readings

​Over the API

What it answers

The three statuses

Why a scheduled run was skipped

When something on our side stops

When a block is yours

Credits stop runs, not readings

Over the API