Failing Closed: When the Safe Answer Is No

Every system eventually reaches a moment where it cannot finish a check. The payment provider does not respond. The permission service times out. A required setting is missing. The code has to decide: carry on as if the check passed, or stop.

Carrying on is called failing open. Stopping is called failing closed. For the parts of our platform that involve money, access or spending, we fail closed.

Two ways to fail

Consider a door with an electronic lock. If the power goes out, the lock can either release, so people can leave, or stay locked, so nobody can enter. Both are reasonable in different buildings. A fire exit should fail open. A safe should fail closed.

Software makes the same choice constantly, often without anyone deciding on purpose. Our goal is to decide on purpose, and to choose the safe default for each kind of risk.

Money fails closed

When a customer pays for a plan, credits or an add-on, our platform sends the charge through our shared payment hub. If that hub is selected but unavailable, the payment does not quietly switch to another route. It stops and tells the customer to try again.

A silent fallback might seem friendlier, but it creates two payment paths with different records, different reconciliation and different refund handling. When something goes wrong later, nobody can be sure which path a charge took. You can read more in no silent fallbacks in payment code.

Paid access works the same way. Only a verified, signed confirmation of payment grants access, extends a subscription or adds value to a wallet. A redirect back from a checkout page is not proof, and neither is a customer saying they paid.

Access fails closed

Permissions are checked on the server for every page, action, download and background job. If the system cannot determine that someone is allowed to do something, the answer is no. A missing role, an expired session or an account that cannot be identified all result in refusal, not in a best guess.

Features that are not ready follow the same rule. When we hold a module back, it is hidden not only from menus but from direct addresses and from the interactive components on the page, so nobody can reach it through a side door.

Uncertain outcomes stop instead of retrying

Some outside actions can end in genuine uncertainty. A request to register a domain or generate an image might time out after the provider has already started the work. Retrying blindly could buy the same domain twice or charge for the same image twice.

In those cases our systems record the uncertainty and lock the operation against replay. A person checks what actually happened with the provider, and only then is the outcome settled. Waiting is better than paying twice.

AI features fail closed too

Our platform keeps a registry of every AI feature, with its purpose, cost and billing rules. Before an AI call is made, the system checks the registry. An unregistered call is refused before anything is spent. If the AI service we route through fails, the request does not fall back to a different provider on a different bill. It reports the failure clearly.

Good error messages are part of failing closed

Refusing safely is only half of the design. The other half is telling people what happened and what they can do. "Something went wrong" is not enough. A useful message says whether anything was charged, whether the action can be retried and where to get help. Internal details, such as error codes and server responses, go to our logs rather than to the screen, both because they confuse people and because they can reveal more about our systems than visitors should see.

The cost of failing closed

Failing closed is not free. Sometimes a customer cannot complete a purchase during an outage, or a feature is unavailable until a problem is fixed. We try to soften that with clear messages, easy retries and fast fixes. But we would rather inconvenience someone briefly than charge them wrongly, expose their data or grant access that should not exist. Those mistakes are much harder to take back. The same thinking shows up in why a hidden button is not security and across our Technology & Impact work.

Frequently asked questions

What does fail closed mean in software?

It means that when a check cannot be completed, the system refuses the action rather than allowing it. It is the safe default for payments, permissions and security.

Is failing closed bad for customers?

It can cause brief inconvenience during an outage, but it prevents much worse outcomes such as double charges, wrong access or data exposure.

When is failing open appropriate?

For low-risk features where availability matters more than precision, such as showing a page with a less personalized layout when a recommendation service is slow.