# When the system is down, what does your operation do? > An outage is a technology event. What the operation does next is an architecture decision. What CMC, AWS and hospital data show, and four decisions to make. - Author: Marlon Trettin - Published: 2026-10-29 · Updated: 2026-10-29 - Language: en - Canonical: https://yowpi.com/en/blog/when-the-system-is-down-what-does-your-operation-do --- Your system will be down at some point, so the useful question is what your operation does while it is. Decide it before the outage: which few transactions keep running, what minimum record they leave, who declares the outage over, and how the work returns to the system. A fallback nobody designed is improvisation. ## TL;DR - AWS's own summary dates an event that began with a DNS fault in one region from 11:48 PM PDT on October 19, 2025, to 2:20 PM PDT on October 20, with IAM and console sign-in among the affected services. A system you did not build can stop for most of a working day. - The Cyber Monitoring Centre modeled the Jaguar Land Rover production halt at roughly five weeks and about £1.9 billion for the UK, a scenario estimate and not audited accounts. - A review of US hospital downtime counted 701 days of downtime across 166 hospitals, and found staff falling back on paper methods they rarely practice. - The fix is architectural: four decisions made before the outage, then a short drill so that people have done it once. ## How long can a system you depend on stay down? Longer than a lunch break, and not always for a reason you control. [AWS's post-event summary](https://aws.amazon.com/message/101925/) describes an event in its N. Virginia region that started at 11:48 PM PDT on October 19, 2025, and ended at 2:20 PM PDT on October 20. The cause was a timing bug in the automation that manages DNS for DynamoDB, which left a service endpoint with an empty record that the automation did not repair. The affected services included IAM and console sign-in. Dependence on this kind of infrastructure is broad. A [July 2026 analysis from the Cyber Monitoring Centre and Parametrix](https://cybermonitoringcentre.com/2026/07/09/new-analysis-from-the-cyber-monitoring-centre-and-parametrix-provides-insights-into-the-uks-growing-reliance-on-cloud-services/) says more than 60% of UK companies depend on cloud services for critical functions. It estimates that a 24-hour outage of the AWS region in Dublin could cause estimated revenue losses of £1 billion among companies that use it directly, excluding downstream effects. Two limits apply. The CMC figures are modeled scenarios, and the cases involve large companies. None of these sources measures a company of 60 people, so the mechanism transfers and the figures do not. ## What does an outage cost when nobody planned for it? Most of the cost is the time the operation stands still. The Cyber Monitoring Centre's [statement on the Jaguar Land Rover incident](https://cybermonitoringcentre.com/2025/10/22/cyber-monitoring-centre-statement-on-the-jaguar-land-rovercyber-incident-october-2025/) puts the UK impact at £1.9 billion, within a modeled range of £1.6 billion to £2.1 billion, and rates it a Category 3 systemic event. It attributes the vast majority of that figure to lost manufacturing output at JLR and its suppliers. For the production halt of roughly five weeks, the model uses £108 million per week of lost fixed costs and profit. The CMC calls this scenario-based analysis rather than confirmed operational data, and the case is a cyberattack on a very large manufacturer, not an ordinary outage at a small company. What carries over is the shape of the loss. In our reading, the repair is a line item and the weeks without throughput are the bill. ## Why is the fallback usually improvised? Because it lives in someone's memory. A [scoping review of hospital downtime](https://scholars.houstonmethodist.org/en/publications/understanding-the-scope-of-downtime-threats-a-scoping-review-of-d/) in the Health Informatics Journal (2020) found 166 US hospitals with 701 days of downtime across 43 events between 2012 and 2018, and 48.8% of the published events involved cyberattacks. The authors describe clinicians falling back on rarely practiced, paper-based methods. They also found contingency planning mostly set from the top down, and argue for involving the front-line staff who actually run the procedures. Hospitals are an extreme case, but the pattern is familiar in any operation. The fallback is whatever the most experienced person remembers. That is the same weakness as [a system that depends on one person](/en/blog/does-your-internal-system-depend-on-one-person), moved to the day of an outage. And whatever gets written in notebooks, chats and loose spreadsheets during the outage becomes one more of the [process exceptions nobody logs](/en/blog/process-exceptions-the-path-nobody-logs). An outage is a technology event. What the operation does next is an architecture decision. ## Which four decisions turn downtime into a designed mode? The first is the list of transactions that must continue. Not everything does. Pick three to five, usually the ones where a customer or a physical process is waiting: confirming an order, releasing a pick list, recording a shipment, taking a payment. Everything else waits, and saying so out loud is part of the design. The second is the minimum record. The fallback form should capture exactly the fields the system requires for those transactions, nothing more, plus who captured it and when. Give each form a number from a separate series, so a sheet written on Tuesday can be traced to a system record on Wednesday. The third is the trigger and the owner. Someone has to declare that the operation is in fallback mode, and someone has to declare it over. Without a named owner, teams wait too long to switch or switch back while data is still missing. Name a primary and a backup, and write the trigger as something observable, such as fifteen minutes without a successful sign-in. The fourth is the return. This is the step teams most often leave undesigned. Work captured in fallback has to re-enter the system in a defined order, with the fallback number stored in a reference field, a second person comparing the count of forms with the count of entries, and a rule for duplicates. If nobody designs the return, the system recovers and the data does not. Then run it once. The hospital review's point about rarely practiced methods applies to any team. A thirty-minute drill with the people who do the work, not only their managers, will expose most of what the written procedure got wrong. ## What does it look like in a real operation? The scenario below is hypothetical, and its numbers are assumed, not measured. Picture an industrial distributor with a 12-person order desk and a warehouse, running on a hosted order system. Say the desk handles 300 orders on a normal day. Without a plan, the system fails at 9:40 in the morning. Clerks write orders on whatever is nearby. The warehouse asks for pick lists by phone. By early afternoon the same order exists in three versions, and nobody is sure which one the customer confirmed. When the system returns, someone spends the next day reconciling, and two orders ship twice. With the four decisions in place, the same outage looks different. The desk keeps four transactions: new orders, stock confirmation for existing customers, pick-list release for orders already confirmed, and shipment records. Each order goes on a numbered form with the same fields the system requires. The warehouse lead declares fallback after fifteen minutes without sign-in. When service returns, the forms are re-keyed in number order, each form number goes into the order's reference field, and a second clerk checks the counts. The outage still costs time. It no longer costs the integrity of the data. If the system is one you own, the better fallback is built into it. In our [Reatop case](/en/cases/reatop), collectors in hospital basements and disposal areas log weights and compliance checks without a signal, and the app syncs when a connection returns. That design was a response to sites where the connection was unstable. The same pattern applies where the outage is occasional and the cost of losing a record is high. ## Frequently asked questions **My team already works around problems when the system goes down. Why write it down?** Improvisation works as long as the people who have seen it before are present and calm. The cost appears on the return, when three versions of the same record meet, and on the day the experienced person is off. Writing it down turns one person's memory into something the whole desk can run. **Is a fallback worth building for something that happens rarely?** The investment is small if you keep the scope small: three to five transactions, one form, one drill. The comparison to make is with your own figures, such as what an hour of stopped orders costs you in margin and in customers who call a competitor. The sources above show that rare is not the same as never, and the CMC attributes most of the JLR loss to lost output. **We use a hosted system. Isn't continuity the provider's job?** The provider's job is to restore the service. Yours is to run the operation in between. AWS's own summary lists IAM and console sign-in among the affected services. Check what your provider commits to, then design for the hours that sit outside that commitment. ## The next step If you cannot name today the transactions your operation must keep running during an outage, or who decides when it is over, the [Operational Architecture Diagnostic](/en/contact) is a 30-minute conversation to map that gap.