The vibration against the nightstand sounds like a jackhammer in a cathedral. 3:04 AM. The blue light of the phone screen sears into my retinas, a digital needle piercing the fog of a REM cycle. I don’t even have to read the text to know the rhythm of the buzz. It’s the high-priority staccato of PagerDuty. My thumb fumbles over the glass, eventually finding the notification. ‘503 Service Unavailable – Critical.’

I stare at the logs for exactly 14 minutes. The culprit isn’t our code. It isn’t a memory leak or a runaway process or a botched deployment from the afternoon. It’s a third-party API-a ‘gold standard’ vendor-that has decided to fall over in a heap of metaphorical rubble. There is absolutely nothing I can do. I cannot fix their servers. I cannot reroute the traffic. I am simply a human alarm clock, woken up to witness a catastrophe I didn’t cause and cannot cure. I silence the alarm, roll over, and stare at the ceiling for another 24 minutes, wondering why we have collectively agreed that this is a normal way to live.

Universal Principles of Fallibility

I’m a typeface designer by trade-Muhammad K.L.-and I spend my days obsessing over the negative space between a capital ‘H’ and an ‘O.’ You might think my world is far removed from the screaming alerts of a backend server, but the principles of structure are universal. When I’m designing a font, if the kerning relies on the reader ‘guessing’ what the word is, the typeface is a failure. If a system relies on a human ‘reacting’ to a foreseeable failure, the system is a failure.

“I recently sent an email to a major client-44 files of a new serif face-and I forgot to actually attach the files. I hit send, felt that brief moment of professional pride, and then realized 4 minutes later that I had sent a hollow shell of a message. It was a human error, yes, but it was also a failure of my process.”

– The Fallibility of Process

In the world of software, we treat these 3:00 AM wake-up calls as inevitable, like the weather. But they aren’t. They are choices. We choose the vendors. We choose the level of redundancy. We choose to prioritize ‘feature velocity’ over ‘operational silence.’ When we pick a third-party service that lacks true fault tolerance, we are essentially signing a contract that says, ‘I am willing to trade my sleep for a slightly cheaper API subscription.’

The Human Cost of ‘Nines’

Think about the numbers. We talk about ‘three nines’ or ‘four nines’ of availability. We strive for 99.994% uptime. But what does that mean for the human on the other side of the screen? If that 0.006% of downtime always happens in the middle of the night because of a brittle dependency, the ‘nines’ don’t matter. The human cost is 100%. We have normalized a state of high-stress vigilance that is, frankly, unsustainable. We’ve turned engineers into glorified monitors.

I’ve spent 44 hours this month thinking about why we don’t build systems that can simply ‘wait’ or ‘fail gracefully.’ If a vendor goes down, why does the system scream for a human? Why doesn’t it just queue the requests, throttle the traffic, and wait for the heartbeat to return? The answer is usually that we didn’t want to spend the extra 24 hours of engineering time to build a robust retry logic or a circuit breaker. We decided it was cheaper to just wake up Sarah or David.

The Myth of the Hero

I remember talking to a colleague about this. He argued that on-call makes engineers ‘better’ because they feel the pain of their own mistakes. I told him that was nonsense. Feeling the pain of a third-party vendor’s mistake doesn’t make me a better engineer; it just makes me a tired one. It makes me resentful. It makes me want to quit and go design typefaces in a cabin where the only ‘alert’ is the sound of a bird hitting the window.

We need to stop valorizing the ‘hero’ who stays up all night fixing a production issue. That hero is often just a victim of poor planning. The real hero is the architect who spent 14 extra hours designing a system that didn’t need a hero at 3:00 AM. We need to start measuring the quality of our systems by the ‘Mean Time Between Waking Up the Human.’ If that number is low, your system is garbage, no matter how many ‘revolutionary’ features it has.

Caring for the Human Layer

I often think back to that email I sent without the attachment. It was embarrassing. But it didn’t wake the client up. It didn’t disrupt his life. It was a failure in a low-stakes environment. Our software systems, however, are rarely low-stakes. They are the backbone of commerce, communication, and health. Yet we treat the humans running them with less care than I treat the kerning on a cheap flyer.

If we want to fix on-call burnout, we have to stop looking at the rotation schedule and start looking at the dependency graph. We need to ask hard questions about why we are using certain vendors. Are they there because they are the best, or because they were the first result on Google?

The Return to Letters

We deserve systems that allow us to be human. We deserve to sleep through the night knowing that the machines we’ve built are smart enough to handle a 503 error without calling for help. Until we prioritize that silence, we aren’t really engineers. We’re just very expensive batteries for a machine that doesn’t care if we’re tired.

The Sanctuary of Structure

I’m going back to my letters now. They don’t beep. They don’t vibrate. They just sit there, perfectly kerned, waiting for someone to read them at a reasonable hour.