Leading Fast Triage in a High-Priority Incident Call.

Now the pressure is real. An alert fires: parts of the platform are down for customers. In this lesson you join an incident call (war room) as the on-call engineer. Your job is to open the incident clearly, set expectations, and keep the conversation focused while people share partial information. You will listen to a model incident call where the lead stays calm, assigns investigation threads, and avoids speculation presented as fact. You will practise language for impact statements, hypotheses, quick requests (“Can you pull logs around…?”), and escalation. You will also practise turn-taking moves that help in fast calls: interrupting politely, bringing someone in, and summarising every few minutes. Your artefact is a short incident timeline note plus a clear initial incident message for the incident channel. The goal is to sound steady and organised, even when you do not have all the answers yet.

1. Alert fires: opening the incident call calmly.

Right, let’s step into a real on-call moment at Northbank Digital. An alert has fired and customers are reporting issues. In situations like this, your first job isn’t to solve everything instantly. It’s to open the incident clearly, set expectations, and create order so the team can investigate efficiently. In this block you’ll listen to the start of a model incident call. Pay attention to three things: one, how the incident lead states impact and scope without guessing; two, how they set a plan for the next few minutes; and three, the calm “process language” that stops the call turning into noise. After you listen, you’ll answer a few comprehension questions. Don’t worry if you miss a detail on the first listen. In a real call, you often catch information in fragments, and you constantly recap. Focus on the big structure: impact, what we know, what we don’t know yet, and what happens next.

The situation.

You’re the on-call engineer and you’ve just joined a war room call. The goal is not to sound dramatic or to “perform confidence”. The goal is to sound steady and organised, even with partial information.

In the model call you’re about to hear, notice how the incident lead:

• Opens with a clear statement of impact: who is affected and how.
• Separates facts from unknowns (this is where many incident calls go wrong).
• Assigns quick investigation threads with short timeboxes.
• Sets an update cadence, so everyone knows when they’ll hear more.

Useful phrases you’ll hear (listen for these).

These are taken from your phrase bank for this lesson:

• “We have an ongoing incident affecting…”
• “Current impact is…”
• “What we know so far is…”
• “What we don’t know yet is…”
• “Let’s avoid guessing — we’ll confirm and report back.”
• “Next update in twenty minutes.”
• “If you’re not actively investigating, please stay muted.”

What good sounds like in the first 60 seconds.

A strong opening is usually four short blocks, in this order:

1. Impact + scope (who, what, how bad)
2. Facts so far (signals, metrics, reports)
3. Unknowns (what’s not confirmed yet)
4. Plan (threads, owners, next update time)

Keep it short. You can add detail later, once you’ve stabilised the call.

Your task in this block.

Listen once for the overall structure. Listen again for key details you can reuse in your own words.

Practice & Feedback

Listen to the start of the incident call. Then answer these questions in 4–7 short lines.

1. What is the current impact (what can customers not do)?
2. What are two facts the lead mentions (metrics, alerts, symptoms)?
3. What are two unknowns they explicitly keep open?
4. What is the immediate plan (who investigates what, and when is the next update)?

Write your answers as bullet points. Don’t try to be perfect: aim for clear, factual English, like you’d type while listening on a busy call.

2. Stating impact and unknowns without sounding vague.

Now let’s make your language in the opening minute really precise. In an incident, people often do one of two unhelpful things: they either overstate certainty, or they sound so vague that nobody knows what to do next. The sweet spot is factual and time-based: what’s happening, since when, who is affected, and what is not yet confirmed. We’ll focus on three mini-tools today. First, “Current impact is…” followed by a concrete user effect. Second, “What we know so far is…” which anchors you in evidence like alerts, error rates, dashboards, or support tickets. Third, “What we don’t know yet is…” which is powerful because it stops speculation becoming ‘truth’. On the screen, you’ll see examples, plus a quick practice where you rewrite messy, emotional incident language into calm incident-lead language. Aim to sound like someone who is in control of the process, even if the system isn’t behaving.

Why this language matters.

During high-pressure calls, the team is constantly deciding: investigate, mitigate, escalate, or communicate. Your wording influences those decisions. Calm, structured phrasing reduces confusion and prevents blame.

Three sentence frames you can reuse.

Below are three frames that work in almost any incident:

Impact

• “We have an ongoing incident affecting…”
• “Current impact is…”

Known facts

• “What we know so far is…”

Unknowns (kept open on purpose)

• “What we don’t know yet is…”
• “Let’s avoid guessing — we’ll confirm and report back.”

Upgrade: from messy to incident-ready.

Notice how the upgraded versions are (a) factual, (b) specific, and (c) careful with uncertainty.

Small grammar and tone note.

At B2 level, small choices make you sound more credible:

• Use “a subset of customers” rather than “everyone” unless you can prove it.
• Use time anchors (“about eight minutes ago”, “since 09:12 UTC”).
• Use softened uncertainty: “It looks like… but I need to confirm.”

Your goal.

Write like an incident lead who is protecting the team from noise: facts first, unknowns clearly labelled, then next steps.

Practice & Feedback

Rewrite the four lines below into incident-call English. Write one improved line for each.

Rules:

• Keep each line to one sentence.
• Use at least two of these frames: “Current impact is…”, “What we know so far is…”, “What we don’t know yet is…”, “Let’s avoid guessing…”.
• Do not invent technical details that aren’t mentioned.

Imagine you are speaking live on the call, and you want to sound calm and precise.

Rewrite these:

1. “Users are furious, the whole app is dead.”
2. “It’s the database, I’m sure.”
3. “We got some alerts, not sure when, but it’s bad.”
4. “This is probably in every region.”

3. Assigning threads and keeping a clear update cadence.

Next, let’s move from opening statements to the moment where the call either becomes productive, or becomes chaotic. The key skill here is assigning investigation threads with clear owners and timeboxes, while also keeping the incident timeline clean. As the lead, you’ll often say something like, “Can you check the logs around…?” or “Could you look at X and report back in ten minutes?” That language is direct, but it doesn’t sound rude, because it’s precise and it includes a time expectation. You’ll read a short excerpt of war room notes. Your job is to extract the operational essentials: who is doing what, what we’re waiting on, and when we’ll check in again. This is exactly what you’ll need later when you write your incident timeline note and your first incident-channel message. While you read, watch for verbs that show ownership: ‘check’, ‘pull’, ‘confirm’, ‘report back’, ‘escalate’. Those verbs keep the team moving.

From discussion to action.

In a fast incident call, people share partial information. If you don’t convert that into threads + owners + time, the call drifts and you lose minutes.

A practical pattern is:

• Request (specific) + source (logs/dashboards) + time window
• “Can you check the logs around 09:10 to 09:25 UTC?”

• Owner + deliverable + timebox
• “Could you look at auth deploys and report back in ten minutes?”

• Update cadence
• “Next update in twenty minutes.”

What to capture in notes (so you can recap).

When you recap, you’re not repeating everything. You’re selecting the pieces that reduce ambiguity:

1. Impact (current)
2. What we’ve confirmed (facts)
3. Active investigation threads (owner + task)
4. Next step (mitigation, escalation, comms)
5. Next update time

Mini example recap.

“Just to recap: we’re seeing elevated 5xx on the public API. Maya is checking region split on dashboards, Tom is pulling auth logs for the last fifteen minutes, and Lina is summarising customer reports in the incident channel. Next update in twenty minutes.”

Notice how that recap is short, but it gives everyone confidence that the process is under control.

Your task.

Read the incident notes excerpt below. Then identify owners, tasks, and the next update time. This is a reading skill, but it’s also an incident leadership skill: turning messy reality into clear actions.

Practice & Feedback

Read the notes excerpt. Then write:

• 3 action items in the format: “Action item: … (owner: …, due: …)”
• 1 recap sentence starting with “Just to recap: …”

Keep everything strictly based on the text. Don’t add new facts. Aim for calm, operational language you could paste into the incident channel.

Write about 6–10 lines total.

War room notes excerpt (09:20 UTC)

• Alert: public API 5xx spiked at ~09:12 UTC.
• Support: 3 customers report failed login; 2 mention timeouts.
• Maya: dashboards show biggest error increase in EU-West, but needs confirmation.
• Tom: checking auth-service logs 09:05–09:20 UTC; looking for recent deploy/config change.
• Lina: collecting ticket IDs and customer names; will post summary in #inc-payments.
• Lead: keep messages in incident channel. Next update at 09:40 UTC.
• Open question: is the issue limited to EU-West or global?

4. Live chat simulation: keep the war room focused.

Now we’ll simulate the moment where Slack starts moving quickly while the call is still running. This is where strong incident leads add real value: you keep messages structured, you request specific information, and you stop speculation becoming a distraction. You’ll do a short chat-style simulation. You are the incident lead, and the team will message you with updates, questions, and a couple of unhelpful statements. Your job is to respond like a calm professional: thank people, pull out the useful signal, assign the next step, and set a time expectation. Remember the interaction moves from the phrase bank: “Can you check the logs around…?”, “Could you look at… and report back in ten minutes?”, “Let’s avoid guessing — we’ll confirm and report back.” Also, don’t forget the call hygiene line: if people aren’t actively investigating, they should stay muted. Treat this like real work. Short lines. Clear owners. Clear time.

Chat behaviour that helps during incidents.

In #inc-payments (or your incident channel), your messages should do at least one of these:

• Request specific evidence (logs, dashboards, traces) with a time window.
• Assign a thread with an owner.
• Confirm what is fact vs what is still a hypothesis.
• Set cadence: when the next update will come.

Language to keep the channel clean.

Here are some high-value lines that make you sound calm and organised:

• “Thanks. Can you share a screenshot or the metric link?”
• “Can you check the logs around 09:05–09:20 UTC and paste the relevant error?”
• “Let’s avoid guessing — we’ll confirm and report back.”
• “Could you look at region split and report back by 09:35 UTC?”
• “Just to recap: … Next update at 09:40 UTC.”

What to do with speculation.

Speculation isn’t always bad, but it must be labelled correctly.

Unhelpful:

• “It’s definitely the database.”

Helpful:

• “One hypothesis is the database, but we haven’t confirmed. We’re checking X and Y.”

Your simulation.

You’ll receive several chat messages. Reply as the incident lead.

Aim for:

• 1–2 sentences per reply
• clear owner names (even if it’s just “Tom / Maya / Lina”)
• one request or next step per reply

You’re practising leadership language, not just vocabulary.

Practice & Feedback

Chat simulation time. You are the incident lead in the incident channel while the call is running.

Write 4 short replies, one for each incoming message. Keep each reply to 1–2 sentences.

In your replies:

• Assign or confirm an action (who does what).
• Use at least two phrases from the lesson (for example: “Let’s avoid guessing…”, “Can you check the logs around…?”, “Could you look at… and report back in ten minutes?”, “Next update at…”).
• Keep the tone calm and factual.

Label your replies clearly as Reply 1, Reply 2, Reply 3, Reply 4.

Incoming messages in #inc-payments:

1. Maya: “EU-West looks worse, but I’m not 100% sure yet. Graph is noisy.”
2. Tom: “Auth logs show a spike in ‘invalid signature’ errors starting 09:11.”
3. Lina: “Support says customer ACME can’t log in at all. They’re asking if we have an ETA.”
4. Random engineer: “This is definitely because of the release yesterday. We should roll back immediately.”

5. Writing a tight incident timeline note as you go.

Let’s turn the moving parts into an artefact you can actually use: a short incident timeline note. During incidents, writing is not ‘extra paperwork’. It’s how you reduce cognitive load. When people join late, when you escalate, or when you hand over to a different on-call, the timeline is what keeps everyone aligned. A good timeline is simple: time, observation, action, and outcome. Importantly, it avoids emotional language and avoids strong claims that aren’t confirmed. You can include hypotheses, but label them as such. On the screen I’ll show you a clean format you can reuse. Then you’ll write your own timeline for this Northbank incident using the details we already have: alert time, reports from Support, the EU-West signal, and the auth ‘invalid signature’ clue. Keep it short. You’re writing for speed and clarity, not for perfection. Think of it as notes you can paste into the incident channel or into your incident management tool later.

What an incident timeline note is for.

A timeline note is your running log. It helps you:

• recap quickly on the call (“Just to recap…”),
• keep a record for escalation and stakeholders,
• prepare the post-incident write-up.

A simple format that works.

Use a time-based list. Each line should be one event.

Format:

• Time (UTC): Fact / action. (Owner if useful.)

Example lines:

• 09:12: Alert fired for elevated API 5xx.
• 09:18: Support reports failed logins from 3 customers.
• 09:21: Investigation started. Threads assigned (dashboards, auth logs, support summary).
• 09:28: Auth logs show spike in “invalid signature” errors since ~09:11 (Tom).

Language choices that keep you safe.

Because incidents evolve fast, your wording needs to be careful:

• Prefer “reports” / “we’re seeing” over “is” when it’s early.
• Label uncertain items explicitly:
• “Possible correlation: … (not confirmed)”
• “Open question: …”

Useful chunks from this lesson:

• “What we know so far is…”
• “What we don’t know yet is…”
• “Let’s avoid guessing — we’ll confirm and report back.”

Your task.

Write a short timeline note for this incident so far. In the next block, you’ll use it to craft your initial incident-channel message.

Practice & Feedback

Write an incident timeline note with 6–8 lines, using UTC times.

Use only the information we’ve already seen in the lesson (alert time, support reports, region uncertainty, assigned threads, auth error clue, next update time). If you want to add something uncertain, label it clearly as an open question or “not confirmed”.

After the timeline, add one final line: “Next update at …”

Keep it operational and factual. Imagine someone joins the incident late and reads only your timeline to understand what’s happening.

Facts you can use (do not invent new ones):

• Elevated public API 5xx spiked at ~09:12 UTC.
• Support has 3 tickets about failed login; 2 mention timeouts.
• EU-West appears worse, but it needs confirmation.
• Tom is checking auth-service logs 09:05–09:20 UTC.
• Auth logs show a spike in “invalid signature” errors starting ~09:11.
• Lina is collecting customer reports for the incident channel.
• Next update is scheduled at 09:40 UTC.
• Open question: EU-West only or global?

6. Capstone: initial incident message for the channel.

Time to pull everything together. Your final task is the core outcome of this lesson: a clear initial incident message you can post in the incident channel. This message is what sets the tone for the entire response. Done well, it tells the team what’s happening, what we know, what we don’t know yet, and what happens next. Done badly, it creates panic, confusion, or a hundred questions you don’t have time to answer. You’ll write a short message with an incident-lead voice. You’ll include impact, known facts, unknowns, and actions with owners where possible, plus the next update time. You’ll also include a simple instruction for channel hygiene, so the conversation stays usable. As you write, keep the balance we practised: confident about the process, careful about the facts. Use the chunks: “We have an ongoing incident affecting…”, “Current impact is…”, “What we know so far is…”, “What we don’t know yet is…”, and “Let’s avoid guessing — we’ll confirm and report back.” When you finish, you’ll have a message you can realistically reuse the next time an alert fires.

What your initial incident message must achieve.

Think of this as a mini executive summary for engineers. It should reduce questions, not create them.

A strong message usually includes:

Headline + impact

• “We have an ongoing incident affecting…”
• “Current impact is…”

Known facts (evidence)

• Alerts, error rates, customer reports, time started.

Unknowns (explicitly labelled)

• Region scope, root cause, ETA.

Actions and ownership

• Who is checking dashboards, logs, comms.

Cadence

• “Next update at …”

Channel hygiene

• Keep messages in one place; non-investigators muted on the call.

A model you can borrow (adapt it).

Below is a model template. Don’t copy it blindly; adapt it to our incident details.

Template

• We have an ongoing incident affecting …
• Current impact is …
• What we know so far is …
• What we don’t know yet is …
• Investigation threads:
• [Name]: …
• [Name]: …
• Let’s avoid guessing — we’ll confirm and report back.
• Next update at …

Your goal at B2.

Sound:

• steady (not emotional),
• specific (not vague),
• careful with uncertainty,
• action-led (owners and next steps).

Your final performance.

Write the message as if you are about to post it to #inc-payments right now. You can reuse your timeline note from the previous block to keep it accurate.

Practice & Feedback

Write your initial incident message for #inc-payments.

Requirements:

• 120–170 words.
• Include all of these sections in a logical order: impact, known facts, unknowns, investigation threads (with names), and next update time.
• Use at least 5 phrases from the lesson chunk bank (exact or lightly adapted).
• Keep the tone calm. Do not blame a team or mention unconfirmed causes as facts.

After your message, add a final short line: “If you’re not actively investigating, please stay muted.”

This is your capstone artefact: make it something you’d genuinely send at work.

Use these names and roles in your message:

• You: Incident lead (on-call)
• Maya: SRE (dashboards, region split)
• Tom: Backend engineer (auth-service logs)
• Lina: Support liaison (customer reports)

Facts to include:

• Elevated public API 5xx since ~09:12 UTC
• Failed logins and timeouts reported by customers
• EU-West seems worse but not confirmed
• ‘invalid signature’ errors starting ~09:11 in auth logs
• Next update at 09:40 UTC