What happened

A security patch batch included the kernel and glibc, which means a reboot. Thanks to the runbook I polished in my previous post, the site is only down for just under a minute. Still, you can't silently restart a production e-commerce site during business hours, so I had to send an advance notice to the client (a Japanese company).

My first draft was, I thought, thorough and honest: the vulnerability's severity, the CVE number, the risk of leaving it unpatched, why this week was preferable. Then I reread it and realized: the person receiving this will feel anxious before they feel informed.

The trap — the more you explain "why", the more worried they get

To an engineer, laying out all the reasoning is what honesty looks like. But the recipient is not an engineer. A CVE number or the phrase "severity: Important" is not decision-making input for them — it's an alarm. Three paragraphs of justification read as "is this so dangerous that it needs three paragraphs?"

The other trap was manufactured urgency. This patch was rated Important, not Critical. If I write "urgent action required" for an Important-grade patch, I have no words left for a real emergency. For a non-critical patch, the right ask is "let us do this during a quiet window this week" — not a midnight maintenance, not "immediately."

The fix — lock the notice to 4 lines

The notice I actually sent boiled down to these four lines:

1. When: Thu, Nov 12, around 14:00. Total work time: ~5 minutes 2. Impact: For about 1 minute, the site will be unreachable (no page / error page) 3. Verified: The same update has been applied to our dev server and confirmed working 4. Follow-up: We will confirm normal operation and notify you once done

With greetings, the full email was under ten lines. The only technical content was one phrase — "for a server security update." No severity grade, no CVE number. What builds trust is not the detailed explanation; it's line 3: "already verified on the dev server." That single line says "this is not a first attempt in production," and the reply came back as one line: "Understood, please go ahead."

Technical details are for people who ask — and even then, one parenthetical is enough: "it updates glibc (a core Linux library)."

Before sending — confirm the patch is NOT already applied

Right before sending the notice, I checked the server's state. If the nightly auto-patching had already applied the update, the notice itself would be pointless.

# When did dnf last run, and what did it do? sudo dnf history | head -5 # When was the last reboot? uptime -s

I confirmed the update was not yet in dnf history and that uptime -s still showed last month's date — then sent the notice. Announcing an outage for work that turns out to be already done costs you credibility; the next notice gets taken less seriously.

The post-work flow is simple: reboot → check the new kernel with uname -r → confirm the main pages return 200 → reply with a single line: "Work completed; normal operation confirmed." A short completion notice also communicates "it went fine" better than a long one.

Takeaways

  • Lock the pre-maintenance notice to four lines: when, impact, verified, follow-up. A long explanation reads as anxiety fuel, not honesty
  • For non-critical patches, ask for "a quiet window this week." Save the word "urgent" for actual emergencies
  • Leave severity grades and CVE numbers out. The trust-building line is "already verified on the dev server"
  • Before sending, confirm the patch is not already applied, with dnf history and uptime -s

A short notice earns more trust than a long explanation. The moment your explanation gets long, the first thing the reader thinks is: "is something dangerous going on?"