How to Handle a Crisis with AI Notes: Outages, Incidents, and Emergency Response
When an outage or incident hits, your notes become your incident log, communication drafts, and postmortem source. Here is how to capture during a crisis.
It is 2:45 AM and something is broken. A system is down, a customer is escalating, a critical process has failed. You are half awake, trying to assess the situation from fragmented information -- an alert that fired, a message from a colleague who noticed the problem, a customer complaint that landed in a support queue.
In the next few hours, you will need to do several things simultaneously: diagnose what happened, coordinate a response, communicate with affected parties, and document the timeline for a postmortem you do not have time to think about yet. You will also need to do this while your brain is operating at a fraction of its normal capacity, because crises do not respect business hours.
Most teams handle incidents with a mix of Slack threads, emails, ticketing systems, and verbal coordination that never gets written down. The record of what actually happened is scattered across five systems and three people's memories. By the time someone writes the postmortem, half the detail is gone.
Here is how to use your notes as the operational backbone of crisis response -- from the first alert through the postmortem.
Capture in Real Time, Structure Later
When an incident starts, your instinct is to fix it first and document it later. That instinct is correct about priorities and wrong about what "later" costs you. The details that matter most for a postmortem -- exact timelines, what was tried, what failed, who was notified and when -- are the first things to blur in memory.
The lowest-friction approach: open a new note the moment you start responding to an incident. Title it with the date and a brief description. Then capture as you go -- not polished paragraphs, but raw observations in the order they happen.
What this looks like in practice:
2:47 AM -- Alert received. System X showing errors.
2:52 AM -- Checked monitoring dashboard. Error rate spiked at 2:41 AM.
2:58 AM -- Restarted the affected service. No improvement.
3:05 AM -- Identified root cause: configuration change deployed at 2:30 PM yesterday.
3:12 AM -- Rolled back configuration. Service recovering.
3:20 AM -- Confirmed resolution. All metrics returning to normal.
This takes seconds per entry. You are typing a line between actions, not writing a report. But when the dust settles, you have a timestamped incident log that would take an hour to reconstruct from memory.
Voice Mode makes this even easier when you cannot type. Dictate what you are seeing, what you are doing, and what you are deciding. Mem transcribes it. The raw transcript is messy, but it captures the real-time sequence of events more faithfully than any after-the-fact reconstruction.
The Incident Note as Communication Hub
During a crisis, you need to communicate outward -- to affected customers, to leadership, to other teams. These communications need to be accurate, appropriately calibrated, and fast. They also need to be consistent: the message to customers should match the message to leadership should match the internal update.
Draft all incident communications in the same note where you are logging the timeline. This keeps the facts and the messaging in one place. When you need to send an update, you are drafting from the actual timeline, not from your foggy recollection of it.
A common pattern: the incident note contains three sections that evolve in real time. The timeline -- the raw log of what happened and when. The internal update -- what is affected, what is being done, expected resolution time. The customer communication -- the external message in non-technical terms.
Keeping all three in one note ensures consistency. There is no drift between the internal and external versions of events.
For operations teams that handle incidents regularly, this pattern can be templated. Create a standard incident note structure and duplicate it when a new incident starts. The template primes you to capture the right things without having to think about structure while under pressure. More on building operational templates in our guide on how operations managers use AI notes for field teams.
Querying Past Incidents
Incidents do not happen in isolation. The server that failed at 2:45 AM might have shown warning signs three months ago. The customer who is escalating might have experienced a similar issue last quarter. The configuration change that caused the outage might be related to a pattern you have seen before.
This is where Mem Chat turns incident notes into institutional memory. When you are in the middle of a response, you can ask:
"Has this type of issue come up before? What was the resolution?"
Chat searches across all your past incident notes, support logs, and meeting discussions. If a similar failure happened six months ago at a different location or in a different system, it surfaces. If a colleague documented a workaround last time, you find it. The institutional knowledge that usually lives in one person's head -- the person who may not be awake right now -- becomes accessible to whoever is responding.
This pattern also helps with escalation decisions. "How did we handle customer communication the last time this type of outage occurred?" gives you a precedent to follow instead of reinventing the response under pressure.
The Escalation Template
A simple escalation template, stored as a note you can duplicate, eliminates the overhead of drafting communications under stress:
What is needed -- one sentence describing the specific action required
When it is needed by -- a concrete deadline
What happens if it does not arrive -- the consequence of inaction
Three lines. Thirty seconds to fill in. Consistent, clear, and direct. You stop spending fifteen minutes drafting frustrated emails and start spending thirty seconds filling in a framework.
The Postmortem That Writes Itself
The postmortem meeting happens three to five days after the incident. By then, the details have already started to fade. The timeline is fuzzy. The exact sequence of decisions is uncertain. Everyone remembers the resolution but not the three things they tried first that did not work.
With a real-time incident note, the postmortem starts from facts instead of reconstructions. The timestamped log, the communication drafts, and the action items captured during the response become the source material.
Open Chat and ask:
"Based on my incident notes, summarize the timeline, root cause, and response for the postmortem."
Chat produces a structured summary from your raw captures -- the exact sequence of events, what was tried, what worked, and how long the resolution took. You refine and add analysis, but the factual foundation is already solid.
The postmortem also benefits from cross-referencing past incidents. "What are the common themes across our last five incident reports?" reveals systemic patterns -- recurring failure modes, communication gaps that keep appearing, response time trends. These patterns are invisible when each incident is treated as a standalone event. They become obvious when incidents are captured in a queryable system.
Support Tickets as Institutional Memory
For teams that handle customer-facing support alongside incident response, the overlap is significant. A support ticket records the customer interaction. An incident note in Mem records the full context -- what was tried, what the root cause was, how it connects to other issues at the same site or system.
The support ticket closes when the immediate issue is resolved. The incident note persists. The next time a similar problem occurs, you are building on a history of resolved issues that informs faster responses. Each site's collection accumulates support history, configuration details, and incident records. Before responding to a new issue, a quick Chat query tells you what has gone wrong before and how it was fixed. For the full site-collection workflow, see our guide on running multiple projects from one app.
Get Started
Create an incident note template with three sections: Timeline, Internal Update, and Customer Communication. Save it as a note you can duplicate when an incident starts.
The next time something goes wrong, open a new note immediately. Capture the timeline as it unfolds -- one line per observation or action, timestamped.
After the incident resolves, ask Chat: "Summarize the timeline and root cause from my incident note." Use the output as the foundation for your postmortem.
After a few incidents, ask Chat: "What are the common themes across my recent incident reports?" The patterns that emerge will tell you where to invest in prevention.
Crises are inevitable. Losing the lessons from them is not. Every incident you document is both a record of what happened and an investment in handling the next one faster.
