IT operations
Alert triage
Research pilot — simulated example, not a live deployment
Turn an alert stream into a clear queue: what needs attention, why it matters, and who should review it.
See an input and its handoff
Compare the expected behavior in a routine case and an exception.
Agreed rule
A recovery can close only a matching open incident.
Repeated alert
Three alerts, one incident to review.
Example input
- Service
- Checkout API · sandbox
- Signal
- Error rate above the configured 5% threshold
- Events
- 3 matching alerts in 2 minutes · no recovery event
Illustrative output
- Classification
- High · checkout requests may be failing
- Grouping
- 1 incident · 2 duplicate alerts suppressed by rule
- Suggested check
- Review recent releases and upstream error logs
The human handoff
Route to the checkout on-call channel. A responder confirms impact and chooses the next action.
Unmatched recovery
A recovery event without an incident to close.
Example input
- Service
- Checkout API · sandbox
- Signal
- Recovery event received
- Incident reference
- No matching open incident
Illustrative output
- Classification
- Needs review · unmatched recovery
- Incident state
- Unchanged · no incident closed
- Suggested check
- Confirm the event source and incident reference
The human handoff
Ask the on-call team to reconcile the event. Keep the audit trail for the unmatched recovery.
How this agent would work
Group the signal
Apply fixed rules to group duplicate alerts and match recovery events to open incidents.
Explain the urgency
Classify severity, summarize the evidence, and suggest checks for the on-call team.
Route for review
Send the summary to the channel defined in the spec. Keep remediation behind human approval.
Where human judgment stays
- Deduplication and recovery follow explicit rules; the model does not invent incident state.
- Severity and suggested checks support the responder’s judgment. They do not establish a root cause.
- Restarts, configuration changes, and other impactful actions need human approval.
When you build your version
A backend you can inspect and own
- Approved spec
- Define severity rules, duplicate and recovery handling, on-call destinations, and actions that need approval.
- Backend/API
- A generated FastAPI backend, packaged as a versioned artifact. Review its configuration, integrations and deployment requirements for your environment.
- Source code
- Download the project code to inspect, change and run in your own environment.
- Validation results
- Evidence tied to the artifact version and the checks actually run. Include duplicate events, matched and unmatched recoveries, missing context, and escalation boundaries in the test plan.
No validation report is provided for this pilot. The scenarios above illustrate expected behavior, not passed tests.
Read what Axtra validates