4. On-call without burning out

Description

By the end of this lesson you'll be able to organize a sustainable on-call rotation with a small team, you'll know how to make beforehand —not at three in the morning— the decision of what deserves waking someone up and what waits until the next day, and you'll understand alert fatigue not as an annoyance but as a measurable operational failure that breaks the entire system. You'll also build the only workflow in this module: a small weekly announcer of who's on call, made with nodes that exist.

This matters because on-call is the piece of the kit most teams set up wrong, and they always set it up wrong in the same way: they think it's a calendar problem. They put six people on a wheel, each one a week, and feel covered. Two months later the rotation has unraveled on its own, everyone went back to calling you, and the feeling remains that "we already tried and it doesn't work". On-call isn't a calendar: it's an agreement about what interrupts a person's life, who can resolve it, and what that person gets in exchange. The calendar is the easy part and the last one.

Connection to the module: this is the second piece of the kit —on-call— and it comes after the runbook for a hard reason already previewed in lesson 2: an on-call rotation without runbooks is a calendar of distressed people. You can't ask someone to respond if you didn't give them something to respond with. That's why lessons 2 and 3 come first. This lesson also revisits a topic from Module 2 —the alert fatigue from its lesson 7— but from the other side. There you saw it from the machine: how a notice is added, deduplicated, and suppressed so the channel doesn't saturate. Here you see it from the person: what happens to a human being you wake up four times for nothing, and why their reaction —stop reading the alerts— is rational and destroys the system. Both sides are the same problem; Module 2 fixed the source, this lesson looks after the recipient.

The building's night shift

Think of an apartment building with a night doorman.

The doorman isn't there to do the everyday work —that happens during the day, with the manager, the cleaner, the maintenance person—. He's there for one thing: so that if at three in the morning a pipe bursts, or someone gets locked out, or an alarm goes off, there's a person awake who knows what to do or who to call. Most nights nothing happens and the doorman reads a book. That's exactly the sign that the system works.

Now notice what would make that post unbearable, because it's the same thing that burns out a technical on-call:

If they wake him for everything. If every time a cat knocks over a trash can an alarm goes off that forces him to get up, check, and sit back down, in a week that doorman stops reacting to the alarms. And on the day of the real fire, the alarm goes off and he thinks "the cat again" and doesn't get up. The alarm that goes off for everything is an alarm that protects against nothing.

If they didn't tell him what to do. If the doorman doesn't have a list of "if X happens, do Y; if Z happens, call this number", every nighttime event is a personal crisis where he has to improvise alone, tired, unable to consult anyone. That's not a job, it's torture, and nobody puts up with it for long.

If they don't compensate him. If being awake and available all night is treated as if it were the same as a day shift, the doorman burns out and quits, and finding the next one is harder and harder, because the post's reputation gets around.

If there's no relief. If it's always the same person, every night, with nobody else able to cover them, then that person can't get sick, or have a family emergency, or take vacation. The post becomes a cage.

A well-done technical on-call solves those four things: it doesn't wake you for everything (the policy of what an emergency is), it says what to do (the runbooks), it compensates (the agreement with the company), and it has relief (the rotation). Notice that only the last one is the calendar. The other three are what most teams forget, and they're the ones that decide whether on-call survives.

Worked example: Daniela's week, twice

Let's go back to Daniela, who joined two months ago. It's her first week on call. We're going to look at it twice, changing only the alert policy.

Version A — no policy: "notify me of every failure".

Terra Market has its #ops-alerts connected to "any failed execution". This is Daniela's week:

Night	Time	Alert	Did it require action?
Monday	01:14	carrier timed out, a retry resolved it	No
Monday	03:40	inventory-update failed one run, the next one corrected it	No
Tuesday	02:09	A sku with an empty price was set aside in dead_letter	No
Wednesday	04:22	shipment-notify didn't send one email, invalid email	No
Thursday	02:51	The ERP really went down, 23 orders set aside	Yes
Friday	01:30	carrier timeout again	No

Six nights, six interruptions, one that really mattered. But look at what happened to Daniela along the way. Monday she got up twice, looked, there was nothing to do, went back to sleep annoyed. Tuesday she opened the phone half asleep, saw "another inventory one", and without reading it well dismissed it. Wednesday she didn't even get up: she looked from bed and kept sleeping. Thursday —the ERP night, the one that did matter— her phone rang at 02:51 and she, trained by four nights of false alarms, thought "another inventory or carrier thing", silenced the phone, and kept sleeping. She found out about the real incident at 07:10, when Gerardo wrote to the daily channel.

Daniela wasn't negligent. Daniela was trained by the system to ignore the alerts, and she responded rationally to that training. The problem wasn't hers: it was a channel that cried wolf five times before the real wolf.

Version B — with a policy: only what requires action reaches the channel that wakes you.

With the first four rows reclassified —successful retries reach nowhere, set-aside items go to the dead-letter-watch summary in the daily channel, business rejections go to error_log— Daniela's week looks like this:

Night	Time	Alert to #ops-alerts	Did it require action?
Thursday	02:51	The ERP went down, 23 orders set aside	Yes

A single interruption in the whole week. And when Daniela's phone rang on Thursday at 02:51, it had rung zero times before that week. That prior silence is what gave the alarm meaning. Daniela got up, opened the runbook, verified nothing was being lost, and resolved it, exactly as you saw in lesson 1.

What to expect. The difference between the two versions isn't the number of failures —they were the same six events in the system— but how many crossed the boundary to a sleeping person. And the consequence is counterintuitive: the channel that notifies less is the one that protects more.

	Version A (notifies everything)	Version B (notifies what's actionable)
Nighttime interruptions in the week	6	1
Alerts that required action	1	1
Was the real incident handled in time?	No (5 h late)	Yes
Daniela's state at the end of the week	Burned out and distrustful	Tired one night, nothing more

The row that matters most is once again the last one. In version A, Daniela ends the week having learned that on-call is a useless punishment, and that lesson is contagious: she tells the team, and the next person comes into their shift already predisposed to ignore the phone. In version B, on-call is annoying one night and bearable the rest, which is the most an on-call rotation can aspire to and is enough for the system to hold up over time.

The decision is made beforehand, not at 3 a.m.

Here is the central principle of the lesson, and it's so important it deserves to be stated on its own: the decision of what deserves waking someone up is made with a clear head, beforehand, in a thirty-minute meeting —not at three in the morning with the lamp on.

The reason is simple and common sense: at three in the morning, half asleep, nobody makes good decisions about severity. The person who gets the alert isn't in a condition to reason "well, this is a carrier failure that usually resolves on its own, so I can wait, but let me verify that dead_letter doesn't grow…". That chain of reasoning is done badly at that hour. What a half-asleep person can do is look at a written rule and follow it. So the work of on-call consists of moving the whole severity decision from the moment of the incident to an earlier and calm moment.

Think of it as a lifeguard's protocol. The lifeguard doesn't decide at the moment of the drowning whether it's worth going into the water, weighing the surf against their fatigue. That's already decided: there's a written protocol, practiced dry a thousand times, that says exactly what conditions justify going in and which ones require calling for backup. In the emergency, the lifeguard executes, doesn't deliberate. The deliberation happened before, on solid ground, with a clear head.

Your on-call policy is that protocol. And it's built by answering, for each type of failure, a single question —the same one you saw in Module 2 but now applied to the person—:

What would the on-call person do, right now, if they received this? If the honest answer is "nothing, this resolves itself or can wait until tomorrow", then it must not reach the channel that wakes you. Period.

From that question come three levels, which are the translation to "on-call" of the three severities from Module 2:

Level	Wakes you?	Terra Market example	What the person gets
Wake now	Yes, at any hour	The ERP down losing orders; the order-sync trigger dead	Call + Slack with a mention
Waits until tomorrow	No	dead_letter growing but with everything safe; shipment-notify with duplicate emails	Summary in the daily channel
Just logged	No	Successful retries, business rejections	Nothing; it lives in error_log

And the golden rule that decides where each failure goes, the one that makes all the difference and that you already know from lesson 1: a notice can only be postponed if you're sure nothing is being lost in the meantime. A failure where the orders stay safe in dead_letter can wait until morning. A failure where the orders are evaporating can't wait, whether it's three or five. The boundary isn't the hour or the apparent severity: it's whether the damage is contained. That's the same non-negotiable condition of the time windows from Module 2, and here it's what separates a sensible policy from one that discovers a disaster in the morning.

Alert fatigue as a measurable operational failure

In Module 2 you met alert fatigue from the machine. Here you're going to see it for what it is from the operation's point of view: a system failure that can be measured, just as you measure a workflow's error rate.

The operational definition is this: alert fatigue starts when the proportion of alerts that require no action is so high that the person stops reading them all —including the ones that do matter. It's not laziness or a bad attitude. It's a rational adaptation: if 80% of what reaches a channel is noise, the brain learns, correctly, that the most likely bet on a new message is that it's noise, and stops investing energy in reading it. The consequence is that the 20% that did matter gets lost along with the rest.

And here's what makes it dangerous and not just annoying: the system looks healthier the more broken it is. A channel with forty daily alerts looks like a very closely watched channel —"look how much visibility we have"—. In reality it's a channel nobody reads, that is, a system without surveillance with the appearance of having it. The abundance of alerts disguises itself as coverage and is the opposite.

Since it's measurable, it can be watched with a couple of numbers any team can keep:

The actionability rate. Of the alerts that reached the channel that wakes you this week, what fraction led to someone doing something? If of ten alerts, eight required no action, your actionability rate is 20% and fatigue has already started. A healthy on-call lives near 100%: almost everything that wakes someone up deserved to wake them.

The target volume per level. You already saw it in Module 2 and here it's on-call's tool: the "wake now" level should produce zero or one alert most nights. If it starts producing five per night, the problem isn't that there are more failures: it's that something misclassified slipped in, or that the layers of defense from Module 2 stopped doing their job. In either case, it's a sign to fix the classification, never to raise the threshold so they stop coming.

That last point is the most common trap and it's worth naming: when a channel saturates, the instinctive reaction is "I'm going to make it notify me of fewer things" by blindly raising a threshold. That calibrates nothing: it turns off alarms without knowing which. The correct way is the reverse —look at what's arriving that shouldn't, and move it to the level it belongs to—, which is a job of classification, not of silencing.

What makes a rotation sustainable

The calendar is the easy part, but it has decisions worth making well because they affect whether people can stand it.

The shift size. With six people, the natural thing is a weekly rotation: each one a week every six. A week is a good stretch —enough for the person to have continuous context of what's happening, not so much as to exhaust them—. Shorter shifts (a day) fragment the context too much; longer ones (a month) burn out. And a practical rule: if the team is so small that the rotation falls on each person too often, that's a datum about the team, not about on-call. An on-call rotation that falls on two people isn't sustainable, and the answer isn't to squeeze those two more, it's to reduce what on-call has to handle —with better layers of defense from Module 2— or grow the team.

Who can be on call. Not everyone from day one. Daniela, newly arrived, shouldn't have the on-call in her first week of work: first she needs the runbooks, a couple of incidents with company, and to know who to escalate to. On-call is earned by coming in through the door of accompaniment, it's not assigned by calendar. This connects directly to the mistake lesson 2 already named: sharing on-call without first sharing the capability. The correct order is capability first (runbooks + accompaniment), shift after.

Escalation as the net's net. The on-call person is never truly alone: there's always someone to escalate to. In Terra Market, the first level is whoever has the shift; if an incident is beyond them or they can't resolve it, they escalate to the expert person (you) or the lead (Marco). This isn't a weakness of the on-call person: it's what makes it possible for someone inexperienced to take the shift without fear, because they know they won't get trapped with a problem they don't understand. An on-call without clear escalation is an on-call only the experts can take, and that defeats its purpose.

Compensation and limits. Being available off-hours has a real cost in a person's life, and treating it as if it didn't is the surest way for nobody to want to do it. The way to compensate it —time off, pay, whatever the company decides— isn't a technical topic and varies by place; what is non-negotiable is that it be explicitly recognized. And a limit that protects everyone: whoever had a busy on-call night doesn't start the next day as if they'd slept. A team that burns out its on-call people runs out of willing people, and at that point no policy saves the rotation.

The on-call announcer: the only workflow in the module

This is the only moment in the module when we build something in n8n, and it's worth being honest about what it is and isn't. n8n has no "on-call management" feature. There's no screen for who's on shift or an escalation button. What we can do, with nodes that exist, is a small workflow that solves a real and annoying problem: that the whole team knows, without asking, who's on call this week.

The problem it solves is concrete. Without this, when something breaks, the team's first question is "who's on call?", and that question is answered at the wrong time, in the middle of the incident, which is the worst moment. An automatic announcement every Monday eliminates that friction.

The form is simple:

Schedule Trigger ──► Code: "Whose turn is it?" ──► Slack: post to #ops-daily
   (Monday 09:00)        (computes the shift)         (weekly announcement)

The trigger is a Schedule Trigger configured to run on Mondays at 09:00. That node exists and is exactly for this: to run something on a recurring schedule.

The computation is a Code node, and here it's important to respect the n8n 2.x restriction you already know: inside the Code node there are no HTTP requests, no file access, no require of anything external. What there is, is pure logic with the allowed libraries. This computation needs nothing more: it's date arithmetic.

// ============================================================
// Node: Code — "Whose turn is it?"
// Mode: Run Once for All Items
//
// WHAT IT DOES: computes which team member is on call this
//           week, rotating in order by calendar week.
// WHY:      the team must know who responds WITHOUT asking it in
//           the middle of an incident. This posts it every Monday.
// n8n 2.x NOTE: no HTTP or files here. Only logic and 'moment',
//           which is one of the allowed libraries in the Code node.
// ============================================================

const moment = require('moment');

// The rotation order. Daniela is NOT in it yet: she joins when
// her accompaniment ends (see the "who can be on call" policy).
// Adding someone too early breaks the rotation.
const rotation = ['You', 'Marco', 'Sofía', 'Iván', 'Renata'];

// ISO week of the year: a number from 1 to 53 that advances each Monday.
// It serves as a stable index for the rotation.
const week = moment().isoWeek();

// The division remainder distributes the weeks in a cycle over the list:
// week 1 -> index 1, week 5 -> index 0, and so on endlessly.
const onCall = rotation[week % rotation.length];

// The backup is always the next one on the wheel: whoever the on-call
// person escalates to if they need a second hand.
const backup = rotation[(week + 1) % rotation.length];

const message =
  `📟 *This week's on-call (week ${week})*\n` +
  `Responds: *${onCall}*\n` +
  `Backup: ${backup}\n\n` +
  `Runbooks: RUNBOOK-01..04 · Escalation: if it's beyond you, to the backup, ` +
  `and if it continues, to Marco.`;

// We return the text ready for the Slack node to post it.
// The Code node assembles the message; the SENDING is done by the Slack
// node, never this node (n8n 2.x restriction).
return { json: { on_call: onCall, backup, week, message } };

The sending is done by a Slack node that posts {{ $json.message }} to #ops-daily. Remember, once more, the restriction: the call to the service is made by the integration node, not by the Code node.

What to expect. Every Monday at 09:00, the team sees in the channel who responds that week and who the backup is. It's a twenty-minute workflow that eliminates a question that, otherwise, always gets asked at the worst moment. It doesn't manage the on-call —the on-call is managed by the human agreement you set up in the previous sections—; it only announces it, which is precisely what n8n can do well.

An honest limitation worth noting: this announcer doesn't know about last-minute swaps ("this week is mine but I'm traveling, I'm swapping with Sofía"). Those changes are human and are agreed by talking; if they happen often, the list in the code gets edited by hand. Don't try to build a swap system inside n8n: it would be a lot of work to solve something a conversation solves better. The tool does the mechanical part; the people do the human part.

Common mistakes

Setting up on-call as a calendar and nothing more (conceptual). What happens: the team distributes weeks among six people and considers on-call solved. Missing are the policy of what wakes someone up, the runbooks, the escalation, and the compensation. The first busy week, the person on shift suffers, can't resolve anything, and the rotation starts to unravel. Why it happens: the calendar is the visible and easy part of on-call, so the part gets confused with the whole. How to spot it: ask the person on call this week what they'd do with an ERP failure at three in the morning. If they can't answer precisely, on-call is just a calendar. How to fix it: before distributing shifts, have the runbooks (lesson 3), the level policy (this lesson), and the escalation by name. The calendar goes last, not first.

Lowering the noise by blindly raising the threshold (practical). What happens: the channel that wakes you saturates, and so it "stops bothering", someone raises a threshold —"only notify if more than ten fail"—. The noise drops, yes, but alarms that mattered also get turned off, without knowing which. One day a real failure doesn't cross the new threshold and nobody finds out. Why it happens: raising a threshold is a quick action that produces immediate relief, and the cost —the alarms that now don't sound— is invisible until it explodes. How to spot it: if your last change to the alerts was "notify me of fewer things" without having looked at what was arriving, you turned things off blindly. How to fix it: don't lower the volume, fix the classification. Look at what's reaching the channel that shouldn't and move it to the level it belongs to. The goal is that everything that wakes someone up deserves to wake them, not that it wakes fewer people about random things.

Putting someone on call before they can respond (practical). What happens: to "share the load as soon as possible", the newest person is put into the rotation in their first weeks. An incident falls to them, they don't have the runbooks internalized or know who to escalate to, they spend an hour distressed and end up calling you anyway. On top of that, they now associate on-call with that distress. Why it happens: there's pressure to unload the expert quickly, and putting someone on the wheel looks like progress. How to spot it: if someone in the rotation couldn't resolve the most common incident without calling you, they're not ready for the shift. How to fix it: on-call is earned with accompaniment —runbooks read, a couple of incidents lived alongside someone experienced, clear escalation—. Putting someone who can't respond yet on the wheel doesn't share the load: it disguises it and returns it worse.

Exercises

Exercise 1 — Classify the week. Here are six events from an on-call week at Terra Market. For each one, say which level it belongs to —wake now / waits until tomorrow / just logged— and why. Remember the golden rule: it's only postponed if nothing is being lost.

(a) At 02:00, the order-sync trigger stops receiving webhooks entirely; no orders come in. (b) At 03:30, dead_letter has 60 items set aside from inventory-update due to empty prices; the store shows old prices. (c) At 01:00, a carrier retry resolves a timeout on the second attempt. (d) At 04:00, the ERP is slow due to the nighttime peak; some executions time out but are set aside in dead_letter. (e) At 02:45, shipment-notify starts sending duplicate emails in bulk due to a carrier resend. (f) At 05:00, an order is deliberately rejected for coming in with total: 0.

See solution

(a) Wake now. The dead trigger means that no orders come in and they're not being saved anywhere —there's no dead_letter to speak of when the workflow doesn't even start—. It fails the golden rule completely: yes, something is being lost. It's the most serious case of all, because it's also silent: there are no executions in red, there's an absence of executions. Wake at any hour.

(b) Waits until tomorrow. 60 items set aside sounds like a lot, but the right question isn't how many, it's whether they're being lost: they're not, they're in dead_letter, and the store with old prices is better than with bad prices. The golden rule is met. It goes to the daily channel summary. Now, if the next morning they keep growing, that's a bad-data problem from RUNBOOK-03, but during the day.

(c) Just logged —actually not even that: a successful retry finished green and doesn't even reach the error workflow—. It's layer 1 of Module 2 doing its job. If this woke someone up, it would be the first step toward fatigue.

(d) Waits until tomorrow. Nighttime slowness with the orders safe in dead_letter. The golden rule is met. And it's a textbook case for NOT waking: it's expected, it recovers on its own or with a reprocess in the morning, and waking someone for the peak's slowness would only teach them to ignore the channel.

(e) A borderline case, and that's why it's interesting. No money or data is lost —so by the strict golden rule it could wait—, but the damage grows with each minute: they're irreversible emails going out to real customers, and unlike dead_letter, this isn't "contained", it's spilling. Here the reasonable decision is to wake, because containing (pausing the workflow, RUNBOOK-04) stops a damage that otherwise accumulates all night. The golden rule has an implicit second part: not just "is anything being lost?" but "is the damage contained or growing?".

(f) Just logged. It's a deliberate rejection, the system working, not failing (layer 3 of Module 2). To error_log. Worth reviewing during the day in case the total: 0 cases spike —that would be a storefront bug— but at night it's nothing.

Why it works: of six events, only two justify waking someone, and for different reasons —(a) because something is lost, (e) because the damage grows uncontained—. The other four wait or don't even arrive. That distribution is the goal of the policy: that the channel that wakes you be so rare that, when it sounds, nobody hesitates to handle it. Notice that the classification doesn't depend on the hour or the number of cases, but on two questions: is anything being lost? and is the damage contained?

Exercise 2 — Diagnose the fatigue. The Terra Market team keeps a record of its channel that wakes them for four weeks. The numbers: week 1, 12 alerts, 2 required action; week 2, 15 alerts, 1 required action; week 3, 18 alerts, 2 required action; week 4, 20 alerts, 1 required action. Calculate the actionability rate of each week, say what's happening, and propose the correct action and the incorrect one.

See solution

The actionability rates (actions / alerts):

• Week 1: 2/12 ≈ 17%
• Week 2: 1/15 ≈ 7%
• Week 3: 2/18 ≈ 11%
• Week 4: 1/20 = 5%

What's happening: two bad things at once. First, the actionability rate is very low —between 5% and 17%—, which means more than 80% of what wakes someone up didn't require waking them. Second, and worse, the total volume is rising week by week (12 → 15 → 18 → 20) while the real actions stay at one or two. It's the exact signature of alert fatigue settling in: more and more noise, the same real signal, and a falling actionability rate. By week 4, at 5%, it's almost certain the team has already stopped reading the channel attentively.

The incorrect action: raise a threshold so "fewer arrive". It would bring the number down from 20 to, say, 8, and it would feel like an improvement. But it would turn off alarms blindly, and since the ones that matter are only one or two out of twenty, there's a real risk of turning off precisely that one. The symptom —high volume— would be attacked without touching the cause.

The correct action: look at the 20 alerts of week 4 and classify each one by why it reached the channel that wakes you without requiring action. Almost certainly you're going to find they're retries that resolved, set-aside items that should go to the daily summary, or business rejections that should go to error_log. Each one is moved to its correct level. The goal isn't "fewer alerts": it's that the ones that remain have an actionability rate near 100%. If at the end the channel gets 2 alerts and both required action, on-call is healthy, even if the absolute number is small.

Why it works: the actionability rate turns a diffuse feeling —"I get a lot of alerts"— into a number that can be watched and acted upon. And it distinguishes the two possible reactions: lower the volume (which treats the symptom and hides the problem) versus raise the actionability (which treats the cause). An on-call is measured by the second, never by the first.

Exercise 3 — Redesign a broken rotation. Terra Market set up its on-call like this: the six on the team, including Daniela who joined two months ago, rotate one week each; the channel notifies of every failure; there are no written runbooks; and there's no compensation or escalation agreement. After two months, the rotation has unraveled and everything falls back on you. Identify the four mistakes and propose the correct order to rebuild it.

See solution

The four mistakes, which are precisely the four things about the night doorman:

1. Notifies of every failure → guaranteed alert fatigue. The person on shift burns out in their first busy week and learns to ignore the channel. Missing the level policy.

2. No runbooks → every incident is a personal crisis where the person improvises alone and tired. Without the script, on-call is torture and ends up calling you anyway. Missing piece 1 of the kit.

3. Daniela in the rotation from month two → someone without the capability to respond has the shift, suffers, and associates on-call with distress. Missing the prior accompaniment.

4. No compensation or escalation → being available at night is treated as free, and whoever gets stuck has no one to turn to. Missing the recognition and the escalation net.

The correct order to rebuild it, which is the order of the kit pieces:

1. First the runbooks (lesson 3), at least for the three or four most frequent symptoms. Without this, nothing else works.
2. Then the level policy: reclassify the alerts so the channel that wakes you gets zero or one per night. This fixes the fatigue and makes on-call bearable.
3. Then the escalation by name and the compensation agreement, so whoever takes the shift knows they're not alone and that their time is recognized.
4. Only then the calendar, and with Daniela out of the wheel until she completes her accompaniment —runbooks read and a couple of incidents lived alongside someone experienced—.

Notice that the calendar, which was the only thing the team did the first time, is the last step of the rebuild. That inversion of order is the whole lesson: on-call doesn't start with the calendar, it ends with it.

Why it works: the exercise shows that a broken on-call is almost never fixed by adjusting the calendar —which is what intuition asks for— but by building the three things that were missing underneath. And the order matters: the runbooks enable the policy, the policy enables on-call to be bearable, and only a bearable on-call can be distributed on a calendar that survives.

Summary and next step

In this lesson you set up the second piece of the kit. With the image of the night doorman you saw the four things that make an on-call sustainable —that it doesn't wake you for everything, that it says what to do, that it compensates, that it has relief— and you noticed that only the last one is the calendar, which is where most teams start and go wrong. You compared Daniela's on-call week twice and saw that the channel that notifies less is the one that protects more: with "notify me of everything", six interruptions trained Daniela to ignore precisely the one that mattered; with a policy that only lets through what's actionable, a single interruption restored the alarm's meaning. You learned the central principle —the decision of what wakes someone up is made beforehand, not at three in the morning, like a lifeguard's protocol— with its three levels and the golden rule that only what's contained is postponed. You understood alert fatigue as a measurable failure, with the actionability rate and the target volume as its two numbers, and the trap of blindly raising thresholds. And you built the only workflow in the module: the weekly on-call announcer, with a Schedule Trigger and a Code node of date arithmetic that respects the n8n 2.x restriction.

Before moving on you should be able to: classify a failure as wake-now / waits-until-tomorrow / just-logged using the golden rule; calculate an actionability rate and say what to do if it's low; and explain why the calendar is the last step of setting up on-call, not the first.

Up to here you've prepared everything that's decided before the incident: the script (runbooks) and who responds with what criteria (on-call). But the moment comes when something truly big breaks, and there not even the best runbook is enough, because it's not a known symptom with its card: it's an incident that unfolds in real time and has to be run. Lesson 5 is the third piece of the kit: the incident timeline. What you do and in what order —detect, communicate, contain, resolve, verify—, why containing comes before understanding the cause (first you stop the bleeding), who talks to the business while someone fixes and why those two people shouldn't be the same, and the log written while it's happening and not afterward.

Resources

• Schedule Trigger — n8n Docs — the trigger of the on-call announcer, configured to run on Mondays at 09:00.
• Code node — n8n Docs — the node where the shift is computed; remember that in n8n 2.x it doesn't allow HTTP or file access, only logic and the allowed libraries like moment.
• Slack node — n8n Docs — the node that posts the announcement to #ops-daily; the call to the service is made by this node, never by the Code node.
• Handle errors gracefully — n8n Docs — the layers of defense whose good functioning is what keeps the volume of the channel that wakes you low; a healthy on-call rests on them.