Reports and incidents
Turn deploy reports into proactive review loops with daily reports, Worry Inbox, and anomaly incidents.
Releases and Impact Analysis help you investigate interactively.
Reports and incidents help the team keep the same deploy review going even when nobody is actively refreshing a dashboard.
What is on the page
This surface keeps four related records together:
- scheduled daily report runs
- Worry Inbox runs
- anomaly incidents
- outbound delivery history
How to think about this page
This page is not a separate analytics surface.
It is the follow-up layer for the same Deploy Impact Report workflow:
- alerts deliver the report or a warning
- incidents track what still needs attention
- delivery history shows whether the warning actually reached people
When to use daily reports
Use daily reports when the team wants a predictable summary of recent site behavior.
This is the lightweight recurring review loop.
When to use Worry Inbox
Use Worry Inbox when the team wants a higher-signal digest focused on unresolved risk, active regressions, or notable changes.
Think of it as the inbox for things that still deserve attention.
When to use incidents
Incidents are the fastest path for anomaly follow-up.
They can be:
- acknowledged
- ignored
- resolved
This gives the team a simple state machine for active issues without waiting for a new release analysis run.
Recommended workflow
- Open Releases when a new deploy lands.
- Open Impact Analysis when you need broader context.
- Open Reports and incidents when the team needs follow-up, escalation, or audit history.
- Use the incident status and delivery history to keep the response loop explicit.
Next step
- Need to start from deploy evidence: Releases
- Need broader business context: Impact Analysis
- Need repeatable CLI or MCP workflows: Agent, CLI, and MCP workflows