6. Samsara & Moksha

The same alert fires. You have seen it twice already this quarter, so you do not open the runbook. Drain the node, restart the pod, watch the graph climb back to healthy. Ten minutes, maybe eight now that you have the muscle memory. You close the incident and note, with something close to pride, that you are getting fast at this one.

That pride is the trap.

Samsara is the Sanskrit word for the round of birth, death, and rebirth. The usual gloss makes it sound like weary repetition, the same life lived over and over. The Upanishads mean something more precise. Samsara is a cycle with a mechanism, and it turns for exactly as long as its cause is fed.

The Brihadaranyaka Upanishad, in its fourth chapter, has the sage Yajnavalkya describe that mechanism to a king. When the body dies, the self does not simply stop. “Now as a caterpillar, when it has come to the end of a blade of grass, in taking the next step draws itself together towards it, just so this soul in taking the next step strikes down this body, dispels its ignorance, and draws itself together for making the transition.” Read it slowly. The caterpillar reaches the next blade before it lets go of the last. The transition is continuous. There is no moment where the self is between lives.

What drives the reach is action. A few lines on: “According as one acts, according as one conducts himself, so does he become. The doer of good becomes good. The doer of evil becomes evil.” You are not carried onward by accident. You are carried by what you did, and underneath that, by what you still want. And then the exit: “When are liberated all the desires that lodge in one’s heart, then a mortal becomes immortal.” That release is moksha, the end of the mechanism rather than a better version of it. The fuel runs out, and the wheel stops.

Operations has a version of this that it does not usually name. We measure mean time to recovery, MTTR, and we work to bring it down. Faster detection, tighter runbooks, a well-drilled on-call, incident command that runs like a drill. All of it is real skill, and all of it makes us faster at recovering from the incident.

None of it removes the incident. The same class of failure returns next quarter, in a different service, wearing a different trigger, and we recover from it faster than last time, and we log that as progress. We have gotten good at the cycle. We have not gotten out of it. Fast recovery is worth having; it caps the blast radius and buys time to think. Riding the wheel well is a real skill. It is just not the same as stepping off it, and a team can ride beautifully for years without noticing the difference.

The incident cycle is samsara, and the caterpillar is the exact shape of it. You resolve an incident, and the cause it came from is already reaching into the next one. The disk fills again because nothing changed about why it fills. The retry storm comes back because the retries are still unbounded. You closed the ticket, and the cause had drawn itself onto the next blade before you finished the postmortem.

There is a sharper line in that passage. As one acts, so one becomes. The recurring incident is not bad luck that keeps finding you. It is what the system has become, given how it is built and run. A service with no backpressure will fall over under load, and the outage is that nature showing under stress. The system’s incident profile is its karma. (Karma is action and its unavoidable result; samsara is what those results become when they compound into a loop.)

Moksha, then, is a specific and unglamorous act. It is the change that removes the class, not the one that helps you survive it faster. Not “alert when the disk fills,” but “the service stops producing the logs that fill it.” The retry storm needs a bound on the retries themselves, retry budgets and backoff; a tighter runbook only helps you ride it out again. In the Advaita reading the cycle turns on avidya, on not seeing what feeds it, and it ends on jnana, on seeing. The software version is plainer. The cycle persists on not understanding what feeds it, and it ends on starving it.

This is not a call to break every cycle. Some are not worth breaking. The systemic fix can cost more than the recurring incident, and the honest tools of the trade say so out loud. An error budget is a decision to accept a rate of failure on purpose, to spend engineering on the worst recurring classes and to let the cheap, rare ones keep happening. That is choosing to stay on a particular wheel because stepping off it costs more than the ride. Advaita would never counsel staying in samsara. Operations does, deliberately, and it is right to.

And breaking a cycle is not the total liberation the word moksha carries. You remove one class, and the system, still changing, grows new ones. There is no final release in operations, no last incident ever. You get local moksha, one cycle at a time, on a system that keeps generating fresh ones. “The cause” flatters the picture, too. A class of incident usually has several contributing conditions rather than one root, which is why the people who run these postmortems distrust the phrase. You remove the largest contributor and drive the rate down; you rarely excise a class cleanly. And knowing those conditions is not the same as being free of them. You can understand them completely and be unable to remove them this quarter, because the fix lives in a system you do not own or a rewrite no one will fund. Understanding is where the release begins. It is not the release.

The practice that names this well is the blameless postmortem. John Allspaw wrote it up from Etsy in 2012, and Google’s SRE book made it doctrine: after an incident you reconstruct what happened without hunting for someone to blame, because blame makes people hide the very information you need. The part that matters for the cycle is the action items. A postmortem whose actions are all “add monitoring, add a runbook, add an alert” has usually kept you on the wheel; it makes the next instance easier to ride. Not always. When the class was a blind spot no alert would have caught, detection is the fix, and for a failure you can only ever fail over rather than prevent, faster detection is the only fix there is. So judge an action by what it changes, not by its label: does it lower how often this kind of incident happens, or how much it costs when it does, or only the time it takes to recover?

Toil is the same idea pointed at the daily grind. The SRE book defines it as the manual, repetitive, automatable work that scales with the size of the service, and it is blunt that toil is a treadmill. Do it faster and there is simply more of it. You get off by automating the class of work away, which is moksha for toil. The recurring page and the recurring chore are the same wheel, and the way off is the same move: stop getting better at the instance, and remove its cause.

The alert that opened this essay will fire again. If the only thing that changed since last time is how fast you clear it, you already know what next quarter looks like. It looks like this one. The wheel does not turn on bad luck. It turns because its cause is still fed, and it stops when you stop feeding it, and not one incident sooner.