When you design a break-glass path around a blocking gate, should the override cost a click or a ticket?

## Two different things you might be buying When people argue about how hard a bypass should be, they are usually conflating two goals. One is *deterrence*: making the override unattractive so that it is used rarely. The other is *availability*: making sure that when the override is genuinely needed, it works. Friction buys the first at the direct expense of the second, and the trade is worse than it looks, because the deterrent effect of friction is largely illusory. An engineer at 02:00 with a customer-facing outage and a blocked deploy has options that do not involve your override. They can merge with elevated rights, run the deploy by hand, or take the change through a path where the gate does not run. Every one of those is faster than a ticket queue. So an expensive override does not stop the bypass; it stops the bypass from being *visible*. You end up with a control that looks pristine in its own logs and is regularly circumvented outside them. ## Charge in the right currency The cost that actually deters is being seen. A useful override is: - **Attributed.** It records the individual, not a shared account, not a service identity, not "the pipeline". - **Loud.** It notifies someone other than the person pulling it, at the time of the pull - the rule's owner and the security on-call, in a channel a human reads that shift. - **Narrow.** It applies to one change, one service, one run. A flag that persists silences the rule for every later run of that job, and then the record shows one bypass while many changes shipped. - **Reasoned.** A free-text justification captured at the moment, even a bad one, is worth more than a reconstruction later - it tells you what the person believed at the time. - **Followed up.** The pull creates work owed by a name, not a note in a channel that scrolls away. None of those add minutes to an outage. All of them make routine use uncomfortable, which is the deterrent you actually wanted. ## Who may pull it The instinct is to require a second person. It is worth interrogating. During an incident, the responder can already deploy the service - that is what makes them the responder. Requiring an approver who will almost certainly say yes adds a wake-up, a delay, and a rubber stamp that adds no information. In that context, a self-service pull that shouts is more honest than an approval that is theatre. Outside an incident the calculus flips. There is time, the pressure that justified self-service is absent, and a second pair of eyes catches the case where someone is using break-glass to avoid doing the work. So a reasonable split is: emergency path self-service and instrumented, non-emergency path approval-gated and slow. What you must not do is have only the slow path and pretend the emergency case does not exist. The worst arrangement is a shared break-glass credential that several people know. It converts the strongest property of the record - naming a person - into "the break-glass account did it", and it is nearly always chosen because it was easier to set up than per-person authorisation. ## Keeping the cheap path from becoming the normal path The honest objection to a one-click override is that it becomes how the team ships. Three things hold it back. The alert goes to a human other than the user, so someone notices the third time this week. Every pull creates a follow-up assigned by name, so the cost is deferred, not waived. And the pull rate per rule and per team is reviewed on a regular cadence, so the number is looked at by people who can change something. When the number stops being embarrassing to anyone, the control is already gone - the click was never the problem. ## Failure modes **The persistent flag.** A skip variable set once in a deploy job's configuration keeps skipping. Scope the effect to a single run and let it expire by default. **The unreachable approver.** An override that depends on a person who is not on call is unavailable exactly when it is needed. If you require approval, you must roster it. **The unattributed pull.** Shared accounts, shared tokens, and "we all use the same label" all defeat the record. **Cost measured in delay.** Any design whose safety argument is "it takes long enough that people will not bother" is measuring the wrong thing and will lose to the workaround. ## What interviewers listen for The strong answer resists the false dichotomy in the question. It does not pick click or ticket; it says that emergency and non-emergency bypasses are different mechanisms with different costs, and that the emergency one is priced in visibility. Mentioning the workaround - that an override more expensive than the alternative simply moves the bypass out of view - is the observation that separates a candidate who has run a gate from one who has only read about them.