Incident Management

An incident is the record of something going wrong and of everything your team did about it. It holds the severity, who is leading the response, a live timeline of every change and message, and links to the Slack threads, email threads, meetings and documents where the real work happened. Once it is over, the same record carries the review: what contributed to it, what is being changed, and who owns each of those changes.

• Declare in one step. A title and a severity are enough, and everything else can be filled in while you work
• Incident Command System roles: commander, operations lead, communications lead, scribe, subject matter expert and liaison, with handovers kept on the record
• A live timeline that records every severity change, status change, update, comment and attached conversation in the order it actually happened
• Attach a Slack thread, an email thread, a Teams message, a meeting recording or any document by pasting its address
• Response times calculated for you: time to detect, acknowledge, mitigate and resolve
• A human reference such as INC-1042 that is safe to say out loud on a call and to put in a message to a customer, with the prefix and shape configurable per workspace
• The full incident report as a download in PDF, Excel, Word or Markdown, rendered from one source so no two formats can disagree
• On-call rotations, overrides and escalation ladders, so an unacknowledged page moves on to the next person rather than sitting unread
• Signed inbound webhooks from your monitoring, which can declare, update and (if you switch it on) resolve incidents automatically
• Customer communications with an approval gate: nothing reaches a customer without somebody having approved that exact text
• Regulatory notification clocks for GDPR, the SEC rule, DORA and HIPAA, each counting from the event its own regime actually names

• Mitigated and resolved are deliberately different. Mitigated means customer impact has ended, which is the number your customers feel. Resolved means the work is fully closed out. Keeping them apart is what makes recovery time meaningful.
• A resolved incident cannot be edited back into an open one. Its timestamps are what every recovery figure and compliance report is calculated from, so reopening is a separate, recorded action rather than a quiet edit.
• Only the first acknowledgement counts. If a later responder could overwrite it, the acknowledgement figure would improve every time somebody else opened the incident.
• Severity is yours to define. Start from one of four presets (SEV1 to SEV5, SEV0 to SEV5, ITIL P1 to P5, or plain words such as Critical and Minor) and edit the levels, their response targets and whether each one pages. Every incident stores the rank it was declared at, so renaming or retiring a level never rewrites history.
• An incident that turns out to be nothing is marked as a false alarm rather than quietly resolved. A false alarm, a duplicate and expected behaviour are all excluded from every response figure, because a quickly dismissed false alarm flatters the average and a slowly dismissed one wrecks it, and neither describes how well anybody responded to a real problem.
• Reference numbering is configurable in settings. Change the prefix, the padding, whether the year appears and whether the counter resets, per record kind. The samples shown are produced by the same code that assigns real handles.
• The review records contributing factors rather than a single root cause. Complex systems fail through several conditions interacting, and naming one cause usually means naming a person.

1. 1Open Incidents from the sidebar, or press the command key and K and search for it.
2. 2Choose Declare incident, describe the symptom rather than the suspected cause, and pick a severity. Starting high and standing down costs nothing.
3. 3Acknowledge it so the response clock stops and everyone can see it has been picked up.
4. 4Assign the roles. At the very least there should be one person leading, and it should be obvious who that is.
5. 5Post updates as you learn things. These become the narrative of the review, so write them for somebody reading tomorrow.
6. 6Attach the Slack thread, the call and any document, so the whole engagement is readable from one place.
7. 7Move the status to mitigated the moment customer impact ends, not when the work finishes.
8. 8Resolve it when the work is genuinely closed out, then write the review while it is still fresh.

What severity should I use?

Pick the one that matches how many people are affected and how badly. If you are unsure, choose the higher one. Raising severity later loses time that a standing down never costs, and every team that has been burned once errs upward.

Why can I not reopen a resolved incident?

Because the resolution time is what recovery figures and compliance reports are built on. Quietly editing it would change numbers that other people have already relied on, so reopening is a separate action that is recorded as such.

What is the difference between mitigated and resolved?

Mitigated means customers are no longer affected. Resolved means everything is closed out, including the cleanup nobody outside the team ever sees. Reporting only one of them would either flatter your recovery time or understate the work.

Can I attach conversations that happened outside Atlas?

Yes, and this is the point. Paste the address of a Slack thread, an email thread, a Teams message, a Google Meet or Teams call, or any document. Atlas recognises the source, removes tracking parameters and records it once, so two responders pasting the same thread does not create two entries.

Who can declare an incident?

Any member of the workspace. Guests can read but never declare, acknowledge or resolve. Configuration such as the fallback responder list is limited to administrators, because it decides who gets woken up.

Can an assistant help during an incident?

Yes. The Atlas MCP server can list and read incidents, read the timeline, post updates and declare a new one. Resolving an incident and sending a message to customers are deliberately left out, because declaring early is safe and closing early is not.

Something was raised that turned out to be nothing. What do I do?

Resolve it as a false alarm rather than as fixed. It stays on the record, with the note explaining what actually happened, and it is left out of every response figure. The same applies to a duplicate of another incident and to behaviour that turned out to be expected.

Can we use our own severity names?

Yes. Pick a preset in settings and edit it, or build your own levels with your own names, ranks, response targets and paging urgency. Each incident records the rank it was declared at, so retiring or reordering a level later never changes what an old incident meant.

Can we change what incident numbers look like?

Yes, under Settings then Reference numbering. Each record kind has its own series, and you can change the prefix, the separator, the zero padding, whether the year or month appears, and whether the counter resets each year or month. The examples on screen are generated by the same code that assigns real numbers, so what you see is what you get.

Can I get the whole incident as a document?

Yes, in PDF, Excel, Word or Markdown. All four are rendered from the same underlying report, so a PDF sent to an executive and a spreadsheet handed to an analyst cannot describe the same incident differently. The report covers the summary, severity, how it ended, every recorded instant with the response figures derived from them, who responded, the paging history, every written update, the full timeline and every linked conversation.

How do the regulatory clocks know when to start?

Each regime counts from a different event, and Atlas uses the right one: GDPR from when you became aware, the SEC rule from the moment somebody determined the incident was material, DORA from classification, HIPAA from discovery. If the incident does not record the instant a regime needs, Atlas refuses to start that clock rather than counting from something else, because a deadline computed from the wrong event is wrong and looks right. Clocks are always proposed, never started on your behalf: whether a regime applies is a judgement for your own counsel, and the dates are a scheduling aid rather than legal advice.

Can somebody send a customer update by accident?

It is hard to. The subject and body that were approved are recorded together as a fingerprint, and that fingerprint is checked again at the moment of sending. Editing an approved update revokes the approval and tells you it has. Sending to an empty recipient list is refused rather than reported as a success, and two people pressing send at the same time results in one message, not two.

Why does the review not have a root cause field?

Because complex systems do not fail for one reason, and a field called root cause invites somebody to name the last person who touched it. The review records several contributing factors instead, and publishing is refused below two of them. It is also refused when no action item has an owner, because an item owned by everybody is owned by nobody.

What happens to the follow-up work from a review?

Each action item can be filed as a real task in a real project, assigned to its owner, with its due date. That is the point: a follow-up that lives only inside a review document is one nobody opens again. Dropping an item instead requires a reason, so a reader six months later can tell a deliberate decision from something that was simply forgotten.