diff --git a/public/uploads/rules/communicate-during-an-incident/rule.mdx b/public/uploads/rules/communicate-during-an-incident/rule.mdx
index 543624e5c42..837d007c457 100644
--- a/public/uploads/rules/communicate-during-an-incident/rule.mdx
+++ b/public/uploads/rules/communicate-during-an-incident/rule.mdx
@@ -1,6 +1,6 @@
 ---
 type: rule
-title: Incidents - Do you know the 4 R's of incident communication?
+title: Do you know the 4 R's of incident communication?
 uri: communicate-during-an-incident
 authors:
   - title: Tom Iwainski
@@ -22,20 +22,16 @@ isArchived: false
 archivedreason: null
 ---
 
-Sooner or later something will go badly wrong. A server dies, the product breaks in production, customer data goes missing, or a release takes the site down.
+Sooner or later something will go badly wrong. A server dies, the product breaks in production, or a release takes the site down.
 
 The technical fix is only half the job. The other half is communication, and that is usually the half that damages the relationship.
 
-You know this rule applies when **someone reaches out about a critical issue**. It might be the CEO, a client, or a Product Owner. Something they rely on is broken, and they are looking to you.
+This rule applies when **someone reaches out about a critical issue**. They may sound stressed or upset, which is fair. The severity is set by the impact on them, not by how hard the fix looks to you.
 
-They may sound stressed, frustrated, or upset. That is a fair reaction when something important is broken, so take it as a signal of how much this matters to them.
-
-The severity is set by the impact on them. It is not set by how hard the fix looks to you, so don't spend time deciding whether it really counts. If it is urgent to them, treat it as urgent.
+<endIntro />
 
 Most incidents go pear-shaped for one reason. It is rarely that the fix took too long. It is that the person who raised it was left wondering whether anyone cared.
 
-<endIntro />
-
 <boxEmbed
   style="info"
   body={<>
@@ -51,7 +47,7 @@ Most incidents go pear-shaped for one reason. It is rarely that the fix took too
 
 If your team has an on-call roster or agreed response times, follow those. Otherwise, the clock starts **when you see it**. Once the message is in front of you, act on it straight away rather than reading it and coming back to it later.
 
-**📞 Call, don't chat**
+#### 📞 Call, don't chat
 
 Chat is the wrong tool for an incident. It is slow, it is easy to misread, and a long back and forth reads as a lack of urgency.
 
@@ -68,16 +64,16 @@ Send one quick line so they know the message has landed, then call.
 
 Pick up the phone even if you are nowhere near your computer. You can often still help verbally.
 
-**🤝 If you can't help, still point the way**
+#### 🤝 If you can't help, still point the way
 
 If you truly can't help, say so straight away so nobody is left waiting on you. Then keep going. "Sorry, I can't help" on its own leaves the person exactly where they started, and it reads as though you have handed the problem back.
 
 Even when you are the wrong person, you can still move things forward:
 
-* **Name someone who might know**, even if you are not certain. A maybe is far more useful than nothing.
-* **Split the chasing.** Offer to call one person while they try another. It halves the time and shows you are in this with them.
-* **Say what you can still do.** Perhaps you can't debug it, but you can check the monitoring on your phone or find a phone number for them.
-* **Come back either way.** Tell them you will report back once you have tried, even if the answer is that you got nowhere.
+* **Name someone who might know** - a maybe is far more useful than nothing
+* **Split the chasing** - offer to call one person while they try another
+* **Say what you can still do** - you might not be able to debug it, but you can check the monitoring from your phone
+* **Come back either way** - report back once you have tried, even if you got nowhere
 
 <boxEmbed
   style="greybox"
@@ -90,13 +86,13 @@ Even when you are the wrong person, you can still move things forward:
 
 This costs you very little, and it is the difference between the stakeholder feeling passed over and feeling helped.
 
-**🙏 Use the 3 A's**
+#### 🙏 Use the 3 A's
 
 Follow [Communication - Do you know the 3 A's for receiving feedback/criticism?](/how-to-take-feedback-or-criticism):
 
-1. **Acknowledge** the issue. *"Yes, the site is down, I can see it too. That's a problem."*
-2. **Apologize** for the impact. *"Sorry, I know this is affecting the demo tomorrow"*
-3. **Act** by saying what you are doing next. *"I'm heading home now and will be online in 30 minutes"*
+1. **Acknowledge** the issue - *"Yes, the site is down, I can see it too, that's a problem"*
+2. **Apologize** for the impact - *"Sorry, I know this is affecting the demo tomorrow"*
+3. **Act** by saying what you are doing next - *"I'm heading home now and will be online in 30 minutes"*
 
 Acknowledging is not just confirming the facts. Agree that it is a problem and that it is bad. The person needs to hear that you are on the same side of it, not that you have simply logged what they said.
 
@@ -118,7 +114,7 @@ Acknowledging is not just confirming the facts. Agree that it is a problem and t
   figure="Agrees it is bad, so the person knows you are taking it as seriously as they are"
 />
 
-**⏰ Be specific about your availability**
+#### ⏰ Be specific about your availability
 
 Never leave someone guessing when you will be back. A vague answer forces the stakeholder to either wait and hope, or chase you.
 
@@ -151,7 +147,7 @@ Never leave someone guessing when you will be back. A vague answer forces the st
 
 ### 2. Reinforce - don't go solo
 
-**👥 Bring in a second person early**
+#### 👥 Bring in a second person early
 
 A second person is not a luxury during an incident. They halve the stress. They spot the thing you are staring straight past. Best of all, one of you can keep the stakeholder informed while the other investigates.
 
@@ -170,7 +166,7 @@ A second person becomes a shield. They absorb the questions, keep everyone infor
 
 Call someone from the team if you can. If nobody from the team is free, grab any co-worker who is.
 
-**🚨 Escalate early if progress has stalled**
+#### 🚨 Escalate early if progress has stalled
 
 It is always better to involve people too early than to sit blocked. Every quiet minute burns the stakeholder's confidence. Escalate as soon as you hit a dead end, and tell the stakeholder you are doing it.
 
@@ -185,7 +181,7 @@ It is always better to involve people too early than to sit blocked. Every quiet
 
 ### 3. Report - while you work
 
-**🔄 Give regular status updates, even when there is no progress**
+#### 🔄 Give regular status updates, even when there is no progress
 
 Silence is the single biggest cause of "they don't care about this". Short updates every **15-30 minutes** keep everyone calm during a major incident.
 
@@ -200,7 +196,7 @@ If you need a longer block of time to investigate, say so upfront so nobody is l
   figure="Sets expectations for a quiet period, so silence doesn't get read as neglect"
 />
 
-**🔓 Surface blockers loudly**
+#### 🔓 Surface blockers loudly
 
 If you are waiting on another person, chase them actively. Call, message, use whatever works. If you still can't reach them, don't go quiet. Tell everyone that you tried, what is blocking you, and what happens next.
 
@@ -213,7 +209,7 @@ If you are waiting on another person, chase them actively. Call, message, use wh
   figure="Shows the chase is active and timeboxed, not a passive wait"
 />
 
-**🔥 Never downplay the urgency**
+#### 🔥 Never downplay the urgency
 
 A statement that pushes the problem into the future tells the stakeholder you have mentally clocked off.
 
@@ -237,23 +233,19 @@ A statement that pushes the problem into the future tells the stakeholder you ha
 
 ### 4. Resolve - and follow through
 
-**📌 Make the incident the highest priority on the next business day**
+#### 📌 Make the incident the highest priority on the next business day
 
 An incident over a weekend is not over when the service comes back up. On the next business day:
 
 1. Make it the team's **top priority**, above whatever was already planned
 2. Brief everyone who was not around during the incident, especially anyone who was off
-3. Start the investigation immediately. Don't let it drift into "we'll look next sprint"
+3. Start the investigation immediately, rather than letting it drift into "we'll look next sprint"
 
-## 🎯 Cheatsheet
+<hr />
 
-* **Respond** - "Seen it, calling you now", then call. Acknowledge, apologize, act
-* **Reinforce** - get a second person in early. One person fixes, one person talks
+## Summary
+
+* **Respond** - send "Seen it, calling you now", then call and use the 3 A's
+* **Reinforce** - get a second person in early so one person fixes and one person talks
 * **Report** - an update every 15 to 30 minutes, even when there is nothing new to say
 * **Resolve** - make it the top priority on the next business day
-
-## 💡 Final word
-
-Nobody can see you working. From the outside, an hour of careful troubleshooting looks exactly the same as an hour of doing nothing.
-
-The fix earns you the outcome. The updates earn you the trust.
diff --git a/public/uploads/rules/unplanned-outage-process/rule.mdx b/public/uploads/rules/unplanned-outage-process/rule.mdx
index c23b082d61c..01d973fea38 100644
--- a/public/uploads/rules/unplanned-outage-process/rule.mdx
+++ b/public/uploads/rules/unplanned-outage-process/rule.mdx
@@ -37,7 +37,7 @@ During your course of being a SysAdmin, you will come across many unplanned outa
   body={<>
     For planned outages, see [Outage - Do you have a planned outage process?](/planned-outage-process)
 
-    For how to communicate with stakeholders while the outage is live, see [Incidents - Do you know the 4 R's of incident communication?](/communicate-during-an-incident)
+    For how to communicate with stakeholders while the outage is live, see [Do you know the 4 R's of incident communication?](/communicate-during-an-incident)
   </>}
   figurePrefix="none"
   figure=""