Handle Temporary and Permanent Failures

A transient failure might succeed on a retry. It goes back in the queue. A permanent failure will not succeed no matter how many times you try. It goes to a person.

A stall is neither. Nothing failed and nothing is happening, because a human has not acted. The first guide in this pillar named this and it has its own destination: not the person who is stalled, since they are already not looking, but their manager or the operations owner.

Retrying a permanent failure a thousand times is a misconfiguration a thousand times, and it buries the original error in a log nobody can read. Escalating a transient one wastes somebody's attention on a problem that would have solved itself, and teaches them to ignore the queue in time for the failure that mattered.

Every destination has to be a real owner

Here is the rule this chapter contributes to the capstone, and it is the one that ties the guide together.

No failure may route to a person who is not named as an owner in Chapter 1.

This sounds procedural and it is the single most common way an escalation policy quietly stops working. Somebody writes “escalate to the data team,” and there is no data team on the map. Or “alert the integration owner,” and that role belonged to a contractor whose engagement ended. The alert fires into nothing, forever, and the absence of complaints reads as the absence of failures.

Every destination in your taxonomy has to resolve to an owner on your own map. If it does not, you have either found a missing owner or an alert nobody will ever see.