What a checkup is
A packaged expert procedure your organization runs read-only against its connected systems and its own support operation.
A checkup is a standing procedure — a Snowflake cost review, a SOC 2 readiness walkthrough, an access review — that runs against your systems and your support history and writes up what it found. It runs read-only: it can look at everything it is allowed to reach and change none of it.
Checkups live in the desktop app, under Checkups. Thirteen curated ones are shipped with the app and are there on first launch; org admins can write their own.
A checkup is not a playbook
They are both procedures written for an agent, and that is where the resemblance ends.
| Playbook | Checkup | |
|---|---|---|
| Triggered by | A ticket arriving | You, or a schedule |
| Scope | One ticket | Your whole environment or operation |
| Question | "Why did this break for this customer?" | "What is wrong across all of this?" |
| Output | A root-cause report on the ticket | A report, plus tracked findings |
| Written by | Admins, per ticket class | Admins, per procedure |
A playbook shapes how a ticket is investigated. A checkup is something you run. The two do meet in one place: a finding can be turned into a ticket, and that ticket is then triaged like any other.
Read-only, and not as a matter of prompt wording
Every checkup body ends up as instructions to an agent, and instructions are a
string — a system the agent reads could argue with them. So the read-only guarantee
is not in the prompt. Write, mutate and delete tools are filtered out before any
agent run sees them, by toolPermitted in the tool layer, applied both when a
server connects and again at every dispatch. The rule is deny-by-default:
- A catalog-vetted integration exposes only the tool names this repository has verified as reads against the pinned package version.
- Any other server — including a custom one you add — must annotate a tool
readOnlyHintwith nodestructiveHint, or the tool is not exposed at all.
This is the same filter that governs ticket investigations, and it is global. No checkup can mutate anything, curated or custom, whatever its body says. See Security model for the wider picture.
Recommendations are proposals
A checkup that says drop REPORTING_WH to size M has not dropped anything. Every
recommendation is a suggestion for a human to apply, in the system's own console,
deliberately.
Scope: which systems a checkup may reach
Each checkup has a data sources setting — the MCP servers it is allowed to call. Leaving it empty means all of your organization's servers, which is the right default for a checkup whose whole job is to survey the environment.
Narrow it when a procedure only concerns one system: a Postgres performance checkup pointed at Postgres alone is faster, cheaper, and cannot wander. As with playbooks, narrowing it too far means a real problem living outside the allowlist simply cannot be seen — the report will say so rather than invent something.
Data sources are per-organization configuration. A shipped checkup's content is updated by app upgrades; its data sources, its enabled flag and its schedule are yours and are never overwritten.
Who can do what
| Action | Who |
|---|---|
| Browse the library, read reports and findings | Anyone signed in |
| Ask follow-up questions in a run's thread | Anyone in the organization |
| Run a checkup, schedule it, write or edit one | Org admins |
| Change a finding's status, assign it, make a ticket from it | Org admins |
Authoring is admin-only on purpose: a checkup body is agent instructions that run over organization-wide data sources under the organization's own identity. There is no private, member-authored checkup.