InspectAutomations
Run repeatable Inspect work on schedules and product events.
Feature overview
An automation starts an Inspect session without a person writing a new prompt each time. It combines a reusable prompt, one or more triggers, optional template variables, and destinations for useful results. Every run remains an inspectable session.
Triggers
Use schedules for recurring work such as weekday health checks, GitHub push triggers for repository changes, GitHub status check triggers for CI results, and Datadog triggers for monitor transitions. One automation can have any number of each trigger type; every trigger keeps its own configuration, enabled state, and identity, so you can pause, edit, or remove it independently. Choose the narrowest trigger that represents each real start condition.
GitHub status checks
Select GitHub status check under Add trigger, then choose a repository and one or more results. An optional exact branch name limits the trigger to the branch being checked, not a pull request's target branch. Leave Check names blank for any check, or enter comma-separated names or glob patterns such as buildkite/**.
For “whenever a check fails on master, triage and fix,” select the repository, set Branch to master, keep the default failure results, and write that instruction as the automation prompt. Select the same repository under the automation's repositories so its session starts from the checked branch. The agent receives the checked commit, check name, result, and details link.
The trigger responds to completed check runs and commit status results, including checks on branches without an open PR. It starts one run per matching trigger, check, result, and commit; repeated reports and reruns with the same result on the same commit do not create another run. Check-suite summaries do not create extra runs. Branch-filtered triggers skip events whose branch is unknown. Creating a trigger does not scan existing failures; it responds to subsequent events.
Prompts and variables
Define one responsibility, what evidence Inspect should gather, and what a successful run produces. Template variables let operators supply values while preserving the prompt contract.
State across runs
Use automation_state when one run needs to leave a small value for a future run, such as an external resource ID, cursor, or counter. A run receives a starting-state snapshot captured when the run is created, so queued or overlapping runs do not see updates made after their creation. The run can set, delete, or increment values for future runs. State values are strings; encode small structured values as JSON strings. Keep generated output in its destination rather than copying it into state, and never store credentials or secrets.
Example: update one Notion page
A weekly status automation can create a Notion page on its first run, then save the page ID under notion_status_page_id with automation_state. Later runs use that ID to update the same page instead of creating duplicates. Tell the prompt to replace the saved ID only after it successfully creates a new page when the old one is missing or inaccessible.
Proposals and fanout
Use post_automation_proposal when an automation finds a concrete action that a person should verify before Inspect carries it out. The tool posts an Inspect-managed Slack card with Accept and Reject actions.
Fanout destinations are purpose-routed, not a broadcast list. Give every Slack channel or Team triage board a specific purpose. A run should choose the single most-specific matching destination, send nothing when no purpose matches, and post to multiple destinations only for genuinely distinct findings.
Workspace administrators can create a public Slack channel directly from an automation's channel selector: enter a new channel name and select Create. For an existing private channel, paste its Slack channel link and invite the posting bot before the automation runs. If its custom agent has a dedicated Slack app, invite that bot. Otherwise, invite Inspect; inviting a custom agent's user-group handle does not give the shared Inspect bot access.
Real-life examples
Scheduled maintenance: scan a repository weekly for stale flags, then propose one verified cleanup in the owning team’s channel.
Production signal: react to a Datadog monitor, gather logs and traces, and post an evidence-backed investigation to the service channel.
Feedback triage: review new customer feedback, enrich an existing issue when it matches, and propose a new task only when the request is concrete and novel.
Combine automations with agents
Select an agent under Custom agent, model & repositories when the job needs specialized instructions or access. The automation starts the work and passes in its task-specific prompt. The agent’s prompt, model, and access apply to every run.
A GitHub push automation can send a changed interface to a Design QA agent. The agent checks it against the design system at each breakpoint, then posts screenshots and a ranked list of problems.
A Datadog trigger can send a monitor alert to a Production Triage agent. The agent uses the team’s playbook to review the relevant telemetry and recent deploys, then posts its assessment to the service channel.