Skip to main content

​
Incident Deletion

Aurora does not provide a DELETE endpoint for incidents. Incidents are permanent records that cannot be deleted through the API.

​
Why Incidents Cannot Be Deleted

Incidents serve as a critical audit trail and historical record for:
  1. Compliance and Auditing - Organizations often need to maintain incident records for compliance requirements
  2. Root Cause Analysis - Historical incidents help identify patterns and recurring issues
  3. Postmortem Generation - Resolved incidents can generate postmortem documents for knowledge sharing
  4. Learning and Improvement - Past incidents inform future incident response strategies

​
Alternative Approaches

​
1. Resolve Incidents

Instead of deleting, mark incidents as resolved:
cURL
curl -X PATCH "https://api.aurora.example.com/api/incidents/{incident_id}" \
  -H "Content-Type: application/json" \
  -H "Cookie: session_token=YOUR_SESSION_TOKEN" \
  -d '{
    "status": "resolved"
  }'
Resolved incidents:
  • Are moved out of active incident views
  • Trigger automatic postmortem generation
  • Remain searchable in historical records

​
2. Merge Duplicate Incidents

If you have duplicate incidents, merge them into a single incident:
cURL
curl -X POST "https://api.aurora.example.com/api/incidents/{target_incident_id}/merge-alert" \
  -H "Content-Type: application/json" \
  -H "Cookie: session_token=YOUR_SESSION_TOKEN" \
  -d '{
    "sourceIncidentId": "{source_incident_id}"
  }'
Merged incidents:
  • Are marked with status merged
  • Reference the target incident via merged_into_incident_id
  • Are excluded from the default incident list
  • Preserve their data for historical reference

​
3. Filter Incidents in List View

The incidents list endpoint automatically excludes merged incidents:
cURL
curl -X GET "https://api.aurora.example.com/api/incidents" \
  -H "Cookie: session_token=YOUR_SESSION_TOKEN"
The response only includes incidents with status other than merged.

​
Database Constraints

Incidents have the following cascade deletion relationships: 
-- Child tables that CASCADE DELETE when an incident is deleted:
- incident_alerts (correlated alerts)
- incident_suggestions (suggested actions)
- incident_thoughts (investigation thoughts)
- incident_citations (command executions)
- incident_feedback (user feedback)
- postmortems (generated postmortem documents)
If incidents could be deleted via API, all related data would be permanently lost.

​
Direct Database Access

Direct database deletion is strongly discouraged and should only be performed by database administrators in exceptional circumstances with proper backups.
If you absolutely must delete an incident at the database level: 
-- This will CASCADE delete all related data
DELETE FROM incidents WHERE id = 'incident-uuid';
This operation:
  • Requires direct database access (not available through the API)
  • Permanently deletes all related suggestions, thoughts, citations, alerts, and postmortems
  • Cannot be undone
  • May violate compliance requirements
  • Should only be done with explicit approval and backups

​
Incident Lifecycle States

Instead of deletion, incidents transition through these states:
  1. investigating - Initial state when incident is created
  2. analyzed - Aurora has completed its RCA analysis
  3. resolved - Incident has been resolved (generates postmortem)
  4. merged - Incident was merged into another incident
All states preserve the incident record for historical purposes.

​
Data Retention Policy

Refer to your organization’s data retention policies for guidance on how long incident records should be maintained. Aurora does not implement automatic data expiration for incidents.

Build docs developers (and LLMs) love

Get started for freeTalk to us