Incident Reporting & Response

Create incidents, coordinate response, update stakeholders, link to code fixes, and document learnings — all in one place.

Creating an Incident

1. Go to Incidents in the sidebar
2. Click + New Incident
3. Fill in the required fields:
   • Title — Clear and descriptive: "Payment gateway returning 500s" not "API down"
   • Severity — Critical, High, Medium, or Low
   • Category — Outage, Security, Performance, Bug, Infrastructure, or Data
   • Description — What's happening, what's affected, initial observations
4. Optionally assign to a specific responder (or leave blank for auto-assignment)
5. Click Create

The incident is created with status Triggered and the MTTA clock starts immediately.

Anonymous Reporting

For sensitive incidents (e.g., potential security issues):

1. Toggle Report Anonymously when creating the incident
2. Optionally provide a contact email if follow-up is needed
3. Your identity is hidden from the incident record

Auto-Assignment

FanDesk routes incidents to the right person automatically using three layers of logic, evaluated in priority order:

Layer 1: Incident Rules

Admins configure rules that match incidents based on conditions and assign to a specific person:

Rules are evaluated by priority order. The first matching rule wins and assignment stops — lower-numbered rules have higher priority.

Example rule: Severity=Critical AND Environment=production → Assign to Sarah (on-call lead)

Layer 2: Response Teams

If no rule matches, FanDesk checks the incident's category for a configured response team. Response teams have a three-level escalation hierarchy:

When an incident is created with a matching category:

1. FanDesk finds all Level 3 (Lead) members in that category's response team
2. The first Lead is assigned as the primary responder
3. All Leads in the category receive a notification

If no Level 3 leads exist, FanDesk falls back to Level 2, then Level 1.

Layer 3: Manual Assignment

If no rules match and no response team is configured for the category, the incident remains unassigned. Any responder can manually claim it or an admin can assign it.

Assignment Flow

Incident Details

Each incident record shows:

• Key — Unique identifier (e.g., INC-42)
• Title and description
• Severity and Category badges
• Status — Current lifecycle stage
• Assignee — Current owner with avatar
• Timestamps — Created, acknowledged, and resolved times
• MTTA / MTTR — Calculated automatically
• Activity Timeline — Chronological log of all updates, comments, status changes, and assignments

Responding to an Incident

Step 1: Acknowledge

When you begin investigating:

1. Click Acknowledge on the incident
2. Status changes from Triggered → Acknowledged
3. MTTA is recorded for this incident
4. Your team sees the incident is being handled

Step 2: Post Updates

Keep stakeholders informed throughout the investigation:

1. Click Add Comment or Add Update
2. Write what you've discovered, what you've tried, and what's next
3. Comments appear in the timeline with your name and timestamp
4. Stakeholders following the incident receive notifications

Post frequent updates during active incidents — even "Still investigating, no root cause yet" is better than silence.

Step 3: Change Status

Move the incident through the workflow as it progresses:

• Triggered → Acknowledged — When you start investigating
• Acknowledged → Investigating — When the investigation is actively underway
• Investigating → Resolved — When the issue is fixed and service is restored

Reassigning

If a different person should own the incident:

1. Click the assignee name/avatar in the incident details
2. Search for and select the new assignee
3. The new assignee receives an immediate notification via app and WhatsApp (if configured)

Linking Tasks to Incidents

Connect the fix work to the incident:

1. Open the incident
2. Click Link Task
3. Search for an existing task or create a new one
4. The task appears in the incident's linked items section

When the linked task is completed, it's visible in the incident timeline. This creates a clear connection between the incident and the engineering work that fixed it.

Linking to GitHub

Track the code changes associated with a fix:

1. Click Link GitHub
2. Paste the GitHub issue or PR URL, or select from recently linked items
3. The PR title, status, and CI status appear in the incident record
4. PR status syncs every 5 minutes (open/merged/closed)

This creates a clear record: incident → linked PR → CI passed → resolved.

Resolving an Incident

When the issue is fixed and service is restored:

1. Click Resolve
2. Add a resolution summary (what was done to fix it)
3. Status changes to Resolved
4. MTTR is calculated and recorded
5. All followers and the assignee receive a resolution notification

After resolution, the incident stays in your history for analytics, postmortem, and audit purposes.

Postmortems

For significant incidents (especially Critical and High), create a postmortem to document learnings and prevent recurrence.

What a Postmortem Contains

Creating a Postmortem

1. Open a resolved incident
2. Click Create Postmortem
3. Fill in each section — the incident timeline is pre-populated to help
4. Add action items and assign them to team members
5. Action items automatically create FanDesk tasks with the owner assigned
6. Click Publish to share with the team

Published postmortems are visible to all responders in the Incidents module and are searchable via DeskMate's knowledge graph.

AI-Assisted Postmortems

Ask DeskMate to help draft a postmortem:

• "Generate a postmortem for incident INC-42"
• "Draft the timeline section for last Tuesday's outage using the incident activity"

DeskMate reads the incident timeline and comments to produce a structured postmortem draft for you to review and refine.

---

Next: Learn about incident metrics in Analytics & Metrics.