The 3 AM Pager: A CBT Thought Record for On-Call Anxiety
The piercing shriek of my phone cuts through the silence of my bedroom. It’s 3:17 AM. My heart leaps into my throat, a cold dread washing over me before I even glance at the screen. A SEV1. Production is down.
My mind immediately spirals. "Oh no, not again. What did I break? Is this that flaky service I touched last week? This is going to be a complete disaster. We'll have to roll back, the data will be corrupted, my manager will be furious, and I'll probably get fired. This is it, my career is over."
Sound familiar? If you've ever been on-call, you know this feeling. That gut-wrenching anxiety, the immediate leap to the worst possible outcome. It's a common experience, and it's something I've personally struggled with and have been working to address. As a developer who also cares deeply about mental well-being, I've found that some of the tools we use to understand and debug code can also be applied to debugging our own minds.
One of the most powerful tools I've adapted from Cognitive Behavioral Therapy (CBT) for managing these moments is the Thought Record.
The Trap of Catastrophizing
What I described above – jumping straight to "my career is over" from a pager alert – is a classic example of a cognitive distortion called catastrophizing. It's when we predict the future, and we predict it will be terrible, even if there's little evidence to support that prediction.
For engineers on-call, catastrophizing often manifests as:
- "This outage is going to cost the company millions."
- "I'm going to cause a data loss that's irreversible."
- "I'll look incompetent in front of my team/manager."
- "I'm not smart enough to fix this, everyone will see through me."
- "This is going to be a multi-day incident, and I won't get any sleep."
These thoughts aren't just annoying; they fuel intense anxiety, making it harder to think clearly, problem-solve effectively, and ultimately, resolve the incident. When your fight-or-flight response is in overdrive, your prefrontal cortex (the part responsible for rational thought) takes a backseat.
The good news is, we can learn to identify and challenge these thoughts. That's where the CBT Thought Record comes in.
The CBT Thought Record: Your On-Call Debugger
A CBT Thought Record is a structured way to examine your automatic negative thoughts, weigh the evidence for and against them, and develop a more balanced and realistic perspective. It's like writing a post-mortem for your anxiety, in real-time.
I've adapted a standard thought record into 7 steps, specifically for those high-stakes, middle-of-the-night incidents.
The 7 Steps:
- Situation: What happened? What triggered the anxiety? Be factual and brief.
- Example: "Pager went off at 3 AM for a SEV1:
Service X is returning 500s."
- Example: "Pager went off at 3 AM for a SEV1:
- Automatic Thought: What was the first, immediate thought that popped into your head? This is often the catastrophic one.
- Example: "I'm going to break production worse, I'll get fired."
- Emotion (0-100): What emotion did you feel (e.g., anxiety, fear, dread, anger) and how intense was it on a scale of 0 to 100?
- Example: "Anxiety: 90%"
- Evidence For: What facts or real evidence support your automatic thought? (Be honest, but also critical. Often, there's very little here.)
- Example: "I did deploy a change to Service X yesterday."
- Evidence Against: What facts or real evidence contradict your automatic thought? What's a more realistic view? Consider past experiences, team support, existing processes.
- Example: "My change was reviewed and tested. There's a rollback plan. Other engineers are on-call and available for support. We have runbooks. I've handled SEV1s before. Managers understand incidents happen. Getting fired for one incident is highly unlikely."
- Balanced Thought: Based on the evidence, what's a more realistic, helpful, and balanced way of looking at the situation?
- Example: "This is a serious incident, but I have the skills and team support to address it. My goal is to diagnose and mitigate the issue methodically. Even if my change contributed, the incident process exists to handle this, not to punish me."
- Re-rate Emotion (0-100): How intense is your emotion now, after considering the evidence and forming a balanced thought?
- Example: "Anxiety: 50%"
A Worked Example: The SEV1 Scare
Let's walk through that 3 AM pager scenario using the thought record.
1. Situation: Pager went off at 3:17 AM for a SEV1: Auth service returning 500s.
2. Automatic Thought: "Oh god, it's my fault. I merged that PR yesterday, it must have broken something vital. I'm going to cause a massive rollback, get pulled into an incident review where everyone blames me, and my manager is going to question my capabilities. I might even lose my job over this."
3. Emotion (0-100): Anxiety: 95%, Fear: 85%, Dread: 90%
4. Evidence For:
- I did merge a PR to the Auth service yesterday afternoon.
- The incident started shortly after the deployment window for my team.
- 500 errors are bad, indicating a critical failure.
5. Evidence Against:
- My PR was small, reviewed by two senior engineers, and passed all CI/CD tests.
- The changes were to an isolated part of the service, not core authentication logic.
- The deployment was automated; if there were immediate issues, it should have been caught by canary deployments or health checks earlier.
- Other teams deploy to Auth service daily; it could be anyone's change, or even an external dependency.
- We have detailed runbooks for Auth service incidents.
- I'm not alone; my team lead is also on-call for escalations, and the entire team supports incidents.
- I've successfully resolved complex SEV1s before.
- Our company culture focuses on learning from incidents, not blaming individuals. Managers understand that incidents are a part of complex systems. Getting fired for a single incident, even a serious one, is extremely rare.
- The alert mentions 500s, not data loss or corruption, which is a different class of problem.
6. Balanced Thought: "An Auth service SEV1 is serious, and it's natural to feel anxious. While my recent PR could be a factor, it was thoroughly reviewed and tested. Many things can cause 500s. My priority now is to methodically diagnose the issue using the runbooks, gather data, and leverage team support. I am capable of handling this, and even if my change is implicated, the incident process is about resolution and learning, not individual blame. My job is secure, and this is a challenge I can meet."
7. Re-rate Emotion (0-100): Anxiety: 55%, Fear: 40%, Dread: 30%
Notice the significant drop in anxiety. It doesn't disappear entirely – a SEV1 is still a stressful event – but it moves from paralyzing dread to a manageable level, allowing you to focus on the actual problem.
The Structure in Code
As a developer, I appreciate structured data. Here's how you might represent a thought record in JSON:
{
"records": [
{
"timestamp": "2023-10-27T03:17:00Z",
"situation": "Pager went off at 3:17 AM for a SEV1: `Auth service returning 500s`.",
"automatic_thought": "Oh god, it's my fault. I merged that PR yesterday, it must have broken something vital. I'm going to cause a massive rollback, get pulled into an incident review where everyone blames me, and my manager is going to question my capabilities. I might even lose my job over this.",
"emotion": {
"anxiety": 95,
"fear": 85,
"dread": 90
},
"evidence_for": [
"I did merge a PR to the Auth service yesterday afternoon.",
"The incident started shortly after the deployment window for my team.",
"500 errors are bad, indicating a critical failure."
],
"evidence_against": [
"My PR was small, reviewed by two senior engineers, and passed all CI/CD tests.",
"The changes were to an isolated part of the service, not core authentication logic.",
"The deployment was automated; if there were immediate issues, it should have been caught by canary deployments or health checks earlier.",
"Other teams deploy to Auth service daily; it could be anyone's change, or even an external dependency.",
"We have detailed runbooks for Auth service incidents.",
"I'm not alone; my team lead is also on-call for escalations, and the entire team supports incidents.",
"I've successfully resolved complex SEV1s before.",
"Our company culture focuses on learning from incidents, not blaming individuals. Managers understand that incidents are a part of complex systems. Getting fired for a single incident, even a serious one, is extremely rare.",
"The alert mentions 500s, not data loss or corruption, which is a different class of problem."
],
"balanced_thought": "An Auth service SEV1 is serious, and it's natural to feel anxious. While my recent PR *could* be a factor, it was thoroughly reviewed and tested. Many things can cause 500s. My priority now is to methodically diagnose the issue using the runbooks, gather data, and leverage team support. I am capable of handling this, and even if my change is implicated, the incident process is about resolution and learning, not individual blame. My job is secure, and this is a challenge I can meet.",
"rerated_emotion": {
"anxiety": 55,
"fear": 40,
"dread": 30
}
}
]
}
This structured approach helps you log and review your thought patterns over time, identifying common triggers and automatic thoughts.
A Tool to Help
I've built a free, open-source web tool called the CBT Toolkit to help with this and other CBT exercises. It's a simple, privacy-focused application that runs entirely in your browser. You can access it here:
https://473185670.github.io/cbt-toolkit/
It includes a dedicated Thought Record module that guides you through these steps, allowing you to save your entries locally.
Try This Next Shift
The next time your pager goes off, or even when you're just feeling that low hum of on-call anxiety during your shift, try taking 5-10 minutes to fill out a thought record. You don't need to do it perfectly, and you certainly don't need to do it during the critical phase of a SEV1. Even practicing with hypothetical scenarios or minor incidents can build the skill.
It's a powerful way to regain control over your thoughts, reduce anxiety, and approach incidents with a clearer, more effective mindset. Your mental health is just as important as your code's health, and debugging your mind can lead to better outcomes for both.
Top comments (0)