Runs and findings
Running a checkup on demand or on a schedule, and how a finding keeps its identity from one run to the next.
A run is one execution of a checkup. It produces two things: a markdown report in a chat thread you can keep asking questions in, and a set of findings that are tracked from run to run.
Running one now
Open a checkup and press Run. Org admins only, and one run of a checkup at a time per organization — a second press while one is in flight is refused rather than started, because two runs reconciling the same findings would fight each other.
The run dialog offers an optional focus: free text appended to the procedure for this run only.
Focus on the reporting warehouses; ignore the ETL ones, we know they are oversized.
Ticket #4812 — Shopify order webhooks stopped arriving on Tuesday.
The row appears immediately with status running and fills in when the agent finishes; an agent run takes minutes, so nothing waits on it.
Focus narrows the report, and the report drives the ledger
Anything a run does not report is treated as fixed (see below). So a focus that tells the checkup to skip part of its scope will auto-resolve the findings living in that part. Use focus to add emphasis or to name the incident you care about; avoid using it to switch whole areas off.
Running one on a schedule
A checkup can be scheduled daily, on weekdays, weekly or monthly, at a time you pick in a timezone you pick. Scheduled runs use the same optional focus for every occurrence.
Scheduled runs use the organization's system identity and the configured background AI provider — never a person's own API key — so an on-demand run is a faithful preview of the scheduled one.
The next occurrence is always computed from now. A machine that was off for a week produces one run when it comes back, not a week of backlog.
The report and its thread
The report is written for a person: prose, evidence quoted from what the tools actually returned, and an explicit note of any system that was unreachable and what that leaves unverified. The structured findings travel in a separate block that is stripped before anything is stored in the thread — you never see machine-readable output in a report.
Anyone in the organization can open the thread and ask follow-up questions. A follow-up is an ordinary agent turn over the thread's history, so it can dig further into what the report says without re-running the whole procedure. A run's thread cannot be deleted: the thread is the run's record.
Two failure modes to recognize in a report:
- The run failed. The thread says what went wrong, the row reads failed, and the findings ledger is left completely alone. An agent that crashed reported nothing, and "reported nothing" must never mean "everything is fixed".
- The findings could not be parsed. The prose report is stored and useful, with a note saying the findings list was left unchanged. Same reasoning.
Findings
A finding is one issue, tracked over time. It carries a title, severity (critical, high, medium, low, info), a detail paragraph, the evidence behind it, and a recommendation.
The findings from every checkup are collected in Checkups → Findings, filterable by checkup, status and severity.
Identity across runs
Each finding declares a key — a stable slug for the underlying issue, like
warehouse:REPORTING_WH:idle. The key is combined with the checkup's own key and
hashed into a fingerprint, and that fingerprint is the finding's identity. The
same issue found next month lands on the same row rather than creating a second one,
which is what makes the history meaningful.
Two consequences worth knowing: keys are scoped per checkup, so two checkups can use the same key without colliding — and renaming a checkup's key orphans every finding it has ever produced.
The lifecycle
| State | How it is reached |
|---|---|
| New | The fingerprint has never been seen for this checkup in this organization. New findings are counted on the run row. |
| Open | It has been reported and nobody has closed it. |
| Acknowledged | Someone marked it seen. It stays acknowledged across later runs and still counts as live. |
| Resolved | Either you marked it resolved, or a run stopped reporting it. |
| Regressed | A resolved finding was reported again. The same row reopens, is flagged regressed, and counts as new. |
| Won't fix | You decided it is not worth fixing. |
Absent means fixed. When a run reports a finding the ledger holds and the run does not mention it, that finding is resolved automatically with a timestamp. This is how a checkup closes its own work without anyone tidying up.
Won't fix is sticky. A finding you mark won't fix is never reopened and never counted again, however many times a later run rediscovers it. The run still records that it saw it — still true, still declined — and that is all.
Each run row carries its own counts: how many findings were new, how many are open after it, and how many it resolved.
Acting on a finding
Org admins can:
- change its status — acknowledge it, resolve it by hand, or mark it won't fix;
- assign it to a member, so it has an owner;
- turn it into a ticket, which files it into the queue your team already works from, carrying the detail, evidence and recommendation across. One ticket per finding — pressing the button twice does not create a duplicate.
A ticket made this way is marked as internally generated. It is triaged like any other ticket, and it is never synced back out to a ticket provider.