[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"guide-how-to-plan-for-the-hour-your-provider-is-down::en":3,"guide-related-how-to-plan-for-the-hour-your-provider-is-down::en":17},{"slug":4,"title":5,"excerpt":6,"body":7,"meta_title":5,"meta_description":8,"keywords":9,"category":15,"published_at":16,"updated_at":16},"how-to-plan-for-the-hour-your-provider-is-down","How to Plan for the Hour Your Provider Is Down","One of the services you depend on will be unavailable for an hour, and the decisions that matter are all made before it happens: what each feature does without it, who is allowed to turn things off, what customers are told, and how the backlog is drained afterwards.","\u003Ch2>What this covers, and what it does not\u003C\u002Fh2>\n\u003Cp>Something you depend on will be unavailable for an hour. Not permanently, not catastrophically — just gone long enough that your product has to behave somehow while it is missing. The work worth doing is almost all in advance, because during that hour nobody designs anything; they choose between options that already exist.\u003C\u002Fp>\n\u003Cp>This is not about an interface changing shape underneath you, which how to depend on an API you do not control covers, and it is not about a system that answers wrongly while remaining perfectly available, which is the subject of what to do when an AI feature gets something wrong. It is also not the question of whose fault it is, which the companion guide on responsibility for a rented service takes up. This one assumes the thing is simply not there, whoever is to blame, and asks what your product does about it.\u003C\u002Fp>\n\u003Ch2>Decide per feature: fail, wait, or degrade\u003C\u002Fh2>\n\u003Cp>For every feature that calls something you do not run, there are only three honest behaviours when the call does not come back. It can fail, telling the person plainly that this part is unavailable. It can wait, accepting the request and completing it later. Or it can degrade, doing a lesser version of the job with what it still has.\u003C\u002Fp>\n\u003Cp>Nearly every product should choose differently in different places, and the choices belong in writing as product behaviour rather than left to whatever the code happens to do. A search box that quietly returns fewer results is a reasonable degradation. A billing action that quietly does less is not; it should fail loudly. A generated summary that is unavailable can often just be absent, with the underlying material still readable. The rule of thumb is that degradation is right where the reduced version is still useful and obviously reduced, and wrong where a person might mistake the lesser output for the full one.\u003C\u002Fp>\n\u003Ch2>Say what happens in the interface, not in an error\u003C\u002Fh2>\n\u003Cp>The difference between a professional-feeling outage and a frightening one is mostly wording written when nobody was panicking. A screen saying this feature is temporarily unavailable and your work is saved does three jobs: it names the scope, it reassures about data, it implies a timescale. A generic failure message does none of them, and sends the person to support, which multiplies the cost of the hour.\u003C\u002Fp>\n\u003Cp>Write those strings ahead of time for the two or three dependencies whose absence is most visible, and make sure they are switchable without a deploy — because deploying during an incident is exactly when a second incident is introduced.\u003C\u002Fp>\n\u003Ch2>Separate what can wait from what cannot\u003C\u002Fh2>\n\u003Cp>Work that can be queued should be queued rather than rejected, but only if two conditions hold. The receiving system must tolerate being asked twice, since the safest recovery from an uncertain result is to retry, and a retry against a system that counts each attempt separately turns an outage into a data problem. And the queue must have a limit, with a decision about what happens when it is reached, because an unbounded queue converts a one-hour outage into a much longer one as the backlog is drained into a service that is only just back on its feet.\u003C\u002Fp>\n\u003Cp>The related trap is the retry itself. Every client retrying immediately and simultaneously produces a wave that arrives the moment the provider recovers, which is precisely when it can least withstand one. Spacing retries out, and spreading them so that everyone does not resume at the same instant, is the difference between a recovery and a second failure.\u003C\u002Fp>\n\u003Ch2>Decide who is allowed to switch things off\u003C\u002Fh2>\n\u003Cp>The most common reason a degradation designed carefully is never used is that nobody on duty believes they are allowed to use it. If turning off a feature requires finding someone senior, it will not happen at three in the morning, and the hour will be spent watching the failure instead.\u003C\u002Fp>\n\u003Cp>So say who may do it, in advance and by role rather than by name, and write down the small number of switches they may throw and what each one costs. Handing that authority to whoever is on duty is not a loss of control. It is the only way the plan you wrote gets executed by the person who is actually awake.\u003C\u002Fp>\n\u003Ch2>Write the customer message before you need it\u003C\u002Fh2>\n\u003Cp>Decide two things now: when you say something publicly, and who writes it. Both are much harder to settle mid-incident, when the temptation is to wait for certainty that is not coming. A short note that names what is affected, says what is not affected, and gives a time for the next update is almost always better than silence, and the update time matters more than the explanation — it converts an unbounded worry into a wait.\u003C\u002Fp>\n\u003Ch2>Plan the hour after the hour\u003C\u002Fh2>\n\u003Cp>Recovery is skipped in planning and rarely skipped in reality. Queued work has to drain without overwhelming the thing that just came back. Anything retried needs checking for duplicates. Anything that failed silently while a dependency was missing needs finding, and that is much easier if you decided in advance to record failures somewhere durable rather than only in logs that roll over.\u003C\u002Fp>\n\u003Cp>Then write the review. The useful output is not an explanation of the provider's failure, which you cannot fix, but a list of the places where your product behaved worse than it needed to given that the dependency was gone — because those are yours.\u003C\u002Fp>\n\u003Ch2>Rehearse the smallest possible version\u003C\u002Fh2>\n\u003Cp>All of this stays theoretical until someone turns a dependency off on purpose, controlled, during working hours, and watches what the product does. Start with a single feature in a non-production environment and one question: does the behaviour match what we wrote down? The first rehearsal usually finds that a timeout is far longer than anyone assumed, that a failure in one feature takes an unrelated page down with it, or that the switch meant to disable something does not exist yet. Those findings are cheap on a Wednesday afternoon and expensive at any other time.\u003C\u002Fp>\n\u003Ch2>Know which dependencies deserve this work\u003C\u002Fh2>\n\u003Cp>Not every dependency is worth an hour of planning, and treating them equally is how the exercise stalls before producing anything. Sort them by two questions rather than by importance in the abstract: how much of the product stops if this is missing, and how likely is it that we would notice quickly. A dependency that halts checkout deserves a written plan; one that decorates a rarely-visited page deserves a sentence saying it may be absent. Three or four entries covering the first category is a finished piece of work, worth far more than a complete inventory nobody has decided anything about.\u003C\u002Fp>","Decide in advance what each feature does when a dependency is unavailable: fail, wait or degrade — plus who may switch it off and how to drain the backlog.",[10,11,12,13,14],"graceful degradation","outage planning","dependency failure","incident response","reliability","how-to","2026-09-09T03:30:02+00:00",[18,23,27,31,36,40],{"slug":19,"title":20,"excerpt":21,"updated_at":22},"ai-tool-pricing-models-seat-vs-usage-vs-credits","AI Tool Pricing Models: Seat-Based vs Usage-Based vs Credits","The three common ways AI tools charge — per seat, per usage, and by credits — and how to reason about which one will actually be cheaper for the way your team works.","2026-08-05T14:32:26+00:00",{"slug":24,"title":25,"excerpt":26,"updated_at":22},"how-ai-image-generators-differ-diffusion-vs-the-rest","How AI Image Generators Differ: Diffusion vs the Rest, in Plain Terms","A non-technical explanation of how AI image generators work, why the diffusion approach became dominant, and what practical differences to expect between tools.",{"slug":28,"title":29,"excerpt":30,"updated_at":22},"how-to-automate-your-workflow-without-code","How to Automate Your Workflow Without Code","A practical sequence for building automations that survive: picking the right process, mapping it before touching a tool, and handling the failure cases that break most first attempts.",{"slug":32,"title":33,"excerpt":34,"updated_at":35},"how-to-build-a-chatbot-without-coding","How to Build a Chatbot Without Coding","A practical route to a working chatbot using no-code tools: deciding scope, connecting your own content, handling the questions it cannot answer, and knowing what it will cost.","2026-08-05T14:32:27+00:00",{"slug":37,"title":38,"excerpt":39,"updated_at":16},"how-to-build-an-evaluation-set-that-does-not-go-stale","How to Build an Evaluation Set That Does Not Go Stale","Most evaluation sets are assembled once, from whatever was easy to collect, and then quietly stop representing the work. How to build one from failures you already have, keep it fed from production, protect it from the system it measures, and know when it has expired.",{"slug":41,"title":42,"excerpt":43,"updated_at":44},"how-to-change-a-prompt-without-breaking-production","How to Change a Prompt Without Breaking Production","Prompts get edited in a text box and shipped in seconds, which is why they break things quietly: no compiler, no stack trace, no obvious moment of failure. Give them the release discipline code gets.","2026-08-24T03:30:02+00:00"]