Incident alert triage
Filter noise, check customer impact, propose a severity, and look for a recent change to blame.
Scenario paths
Pick a predefined path to highlight it through the chain. No model is called; outcomes are illustrative.
- Steps
- Endpoints
- Log only
- Attach to open incident
- Alert tuning ticket
- Team ticket
- Notify change owner
- Page incident commander
- On-call review
What each endpoint means
Log only · Automated
Recorded on the service's dashboard; nobody is paged.
Attach to open incident · Automated
Added to the incident's timeline.
Alert tuning ticket · Automated
A ticket for the alert's owner to fix the threshold.
Team ticket · Automated
A ticket in the owning team's queue for working hours.
Notify change owner · Human review
The person who shipped the change is asked to assess a rollback with the on-call engineer.
Page incident commander · Human review
An incident is opened and the commander confirms severity.
On-call review · Human review
The on-call engineer looks at it directly.
Steps
Separate real problems from noise.
- ActionableCustomer impact signal
- Log onlyLog only
- Attach to incidentAttach to open incident
- Tune alertAlert tuning ticket
- On-call reviewOn-call review
Question, inputs and notes
Asks:Does this alert need someone to act on it now?
Receives
- Inputalert
- Inputhistory
- Inputopen_incidents
Find out whether customers are affected.
- Customer impact likelyUnclearProposed incident severity
- No customer impact seenChange-related incident signal
Question, inputs and notes
Asks:Do these signals indicate that customers are affected right now?
Receives
- Inputalert
- Inputcustomer_signals
Branches
- Customer impact likely, Unclear: Unclear impact is treated as possible impact.
Propose a severity for the commander to confirm.
- Propose majorPropose criticalResponder decidesPage incident commander
- Propose minorPropose degradedChange-related incident signal
Question, inputs and notes
Asks:Based on what is known, which severity level fits this incident best?
Receives
- Inputalert and responder notes
- From step 2Customer impact signal
Look for a recent change that explains it.
- Notify change ownerNotify change owner
- No related changeTeam ticket
- UnclearOn-call review
Question, inputs and notes
Asks:Could one of these recent changes plausibly explain this alert?
Receives
- Inputalert
- Inputrecent_changes
About this chain
Goal and input
Every alert ends logged, attached to an incident, sent for tuning, in a team queue, with the change owner, or with an incident commander.
The alert, its history, open incidents, customer signals and recent changes.
- alert
- The alert that fired.
- history
- Fire/resolve counts, computed in code.
- open_incidents
- Open incidents for the service.
- customer_signals
- Recent tickets and synthetic checks.
- recent_changes
- Deploys and config changes with minutes before the alert.
How it runs
- Severity is always a proposal. The commander confirms it, and hard paging rules owned by each team still apply in code.
- Nothing in this chain rolls back, silences or deletes anything automatically.
Sources (3)
Primary documentation this chain builds on.
- SourcedTypeSafe docs · DocumentationSystem One
- SourcedTypeSafe docs · PatternRouting by probability
- SourcedTypeSafe docs · DocumentationModel jaggedness