Summary
- What Garmin confirmed: Garmin said it was the victim of a cyberattack that encrypted some systems on July 23, 2020. The company said many online services were interrupted, including website functions, customer support, customer-facing applications and company communications, while product functionality was not affected except for access to online services.
- What users experienced: The outage turned wearable sync, activity sharing, training history, developer integration, support contact and aviation database workflows into a common service-continuity problem. Local devices still collected data, but several customer and professional workflows depended on Garmin-controlled systems being reachable.
- What remains bounded: Garmin did not publish the initial access method, affected system list, ransom demand, payment decision, restoration sequence, backup design, segmentation map or complete forensic report. Reports naming WastedLocker and describing a decryptor are useful context but should remain third-party reporting, not Garmin-confirmed fact.
- Accountability question: Criminal actors caused the attack. Garmin controlled the architecture, offline continuity options, backup and restoration evidence, customer notices, aviation-update communication, support restart and the public boundary between "products still work" and "services customers rely on are down."
The device was not the whole product
Garmin's outage exposed a simple but often neglected fact: a connected device is only partly a device. The watch, bike computer, chartplotter, handheld GPS or aircraft display may continue to power on, collect sensor data and navigate with already installed information. But the surrounding service determines whether that data synchronizes, whether a training plan is visible, whether a route moves between systems, whether a pilot can buy and install current databases, whether a developer can serve customers, and whether support can answer a problem during a recovery week.
Garmin's own statement makes the distinction. On July 27, 2020, the company said it had been attacked on July 23 and that some systems had been encrypted. It said the outage interrupted online services including website functions, customer support, customer-facing applications and company communications. It also said it had no indication that customer data, including Garmin Pay information, had been accessed, lost or stolen, and that product functionality was not affected except for access to online services. (Garmin July 27 statement)
That sentence pair is the core of the case. Garmin could truthfully say that hardware still functioned while customers could truthfully experience a major service failure. A runner could complete a workout without Garmin Connect. A cyclist could keep a ride on a head unit. A pilot with already current avionics data could keep using certified equipment under the limits of the aircraft, equipment and rules that applied to that flight. Yet the service layer that made those devices useful in daily life was impaired.
The accountable question is therefore not whether every Garmin product failed. It did not. The question is who controlled the centralized systems that made separate products behave like a platform, who controlled continuity plans for those systems, who could communicate the difference between local and online functions, and who could produce evidence that restoration did not conceal a data or safety problem.
Garmin's public record is short but important
Garmin's primary incident disclosure was concise. It said affected systems were being restored, normal operation was expected over the next few days, and the company did not expect a material impact to operations or financial results. It warned that some delays were expected as a backlog of information was processed. That backlog point matters. It shows that restoration was not only a binary act of switching services back on. Garmin had accumulated data, transactions or requests that needed to be processed after services returned.
Garmin later repeated the incident in its 2020 Form 10-K risk discussion. The annual report said independent forensic analysis gave the company no indication that customer data was accessed, lost or stolen. It also said the outage's impact on operations and financial results was not material and was not expected to have material impacts in future periods, while warning that negative consequences could still exceed expectations. (Garmin 2020 Form 10-K)
Those two public records provide a useful but incomplete accountability spine. Garmin confirmed encryption of some systems, broad online-service interruption, a restoration effort, no indication of customer-data compromise, no expected material financial effect and a backlog. It did not publish which systems were encrypted, which systems were shut down defensively, how recovery was prioritized, whether backups were used, whether ransom was demanded or paid, which third parties were retained, which logs supported the data conclusion, or which controls changed afterward.
That incompleteness is not unusual. Companies rarely publish a full ransomware postmortem. But Garmin's product mix made the missing evidence more important than it might be for a single-purpose consumer app. Its services crossed fitness, outdoor recreation, marine, automotive, developer, enterprise and aviation workflows. The same outage could look trivial to one customer and material to another.
Fitness continuity depended on delayed trust
The fitness side of the outage was a cloud-service dependency problem hiding inside personal routine. Garmin Connect is not only a social feed. For many users it is the place where activity history, health metrics, training load, sleep, routes, challenges and third-party sharing are reconciled. Garmin's current Connect privacy page describes a service that can receive activity, location, device, wellness and other account information depending on product and settings. (Garmin Connect privacy information)
During the outage, devices could still record local activity, but users could not depend on ordinary synchronization and review. Some could manually export files if the device and local tools allowed it. Others had to wait. That created a trust gap: would a run or ride be preserved, would a streak count, would a training metric recompute, would third-party services receive the data, and would duplicated uploads create errors after recovery?
The issue sounds small until it is understood as service design. Fitness customers had paid for devices whose value included the cloud service. Developers and coaches built workflows around the platform. Retailers and support teams had to answer confused customers while Garmin's own customer-support channels were impaired. A few days of lost convenience can become a support and reputation load when millions of devices are organized around one synchronization point.
That is the SME continuity angle. A local bike shop, coach, race organizer, wellness program, repair technician or independent app developer may not have a contract that guarantees Garmin uptime. Still, their customer interactions can depend on Garmin services. When a large platform fails, small counterparties absorb explanation costs, manual workaround costs and customer frustration without controlling the recovery.
Aviation made the service layer more serious
The aviation side requires a different tone. Garmin said product functionality was not affected except for online services. That boundary is important and should not be inflated into a claim that aircraft systems were corrupted. The public record does not show a compromise of installed avionics, aircraft navigation sensors or aircraft-control systems.
But aviation depends heavily on current, trusted information. Garmin's flyGarmin site describes flyGarmin as the way to buy and install aviation databases and links to Garmin Aviation Database Manager, database update schedules, database alerts and aviation support material. (flyGarmin) Garmin's aviation database pages describe navigation, chart, obstacle, terrain and other aviation database products. (Garmin aviation databases) When those online services are disrupted, the user experience is not equivalent to losing a music-sync feature.
Pilots and operators generally manage database cycles, subscriptions, planning tools and support windows around flight schedules. If an online account, download, purchase, update or support channel is unavailable, the practical result may be delay, alternate planning, use of already installed data within applicable rules, or deferral of a flight that depends on updated information. Aviation outlets and pilot organizations reported flyGarmin and related service disruption during the 2020 outage, including database-update friction. (AOPA report) (AVweb report)
This is not an allegation that Garmin created unsafe flights. It is a claim about practical control. Garmin controlled the online update and account systems. Pilots controlled go/no-go decisions, aircraft equipment use and regulatory compliance for their operations. Regulators set the rules. When the update service was down, accountability was distributed across those roles, but the recovery evidence sat largely with Garmin.
Ransomware attribution remains a public boundary
Garmin did not publicly name a ransomware family. Several security and technology outlets reported that the incident involved WastedLocker ransomware, and BleepingComputer reported that Garmin later received a decryptor. (BleepingComputer on WastedLocker reporting) (BleepingComputer on decryptor reporting) Those reports are relevant because WastedLocker was publicly associated by researchers with Evil Corp, a group that had been sanctioned by the US Treasury in 2019. (US Treasury Evil Corp action)
The boundary matters. Third-party reporting can establish what journalists and researchers believed they had confirmed from sources and technical artifacts. It does not become Garmin's statement. Without a Garmin report, court record, regulator finding or law-enforcement charging document tied to this incident, the article should not state as proven that Garmin paid a ransom, that Evil Corp directly received money, or that a sanctions rule was violated.
It is still fair to analyze the governance problem. The US Treasury's ransomware advisory warned that payments to sanctioned persons or jurisdictions can create sanctions risk even where a victim is under pressure. (OFAC ransomware advisory) The FBI's general ransomware guidance says the bureau does not encourage paying a ransom because payment does not guarantee data recovery and can encourage further attacks. (FBI ransomware guidance) If a company in Garmin's position considered payment, it would have needed legal, sanctions, insurance, operational and public-interest review. The public record does not disclose whether that review happened because it does not disclose a payment decision.
Recovery was a queue, not a switch
Garmin's statement that backlogged information would be processed is one of the most revealing public facts. A connected-device outage creates deferred work. Devices keep collecting. Users keep exercising. Customers keep seeking support. Developers keep receiving complaints. Aviation users keep approaching database cycles. Orders, tickets, uploads, emails, account actions and support requests may pile up even if the data is not lost.
That backlog creates restoration risk. When a system returns, the first challenge is whether it is clean and stable. The second is whether data arriving after the outage can be reconciled with data captured during the outage. The third is whether support and customer communication can handle the surge. The fourth is whether customers can tell the difference between "service available," "service delayed," "data still processing" and "data unrecoverable."
The public Garmin record does not show a complete recovery curve. It does not show when every service reached normal state, how many activities were delayed, how support call volume changed, which geographies or product lines recovered first, or how many aviation users encountered update problems. Technology outlets reported the outage as affecting Garmin Connect, call centers, websites and aviation services, and TechCrunch described the company confirming a cyberattack after days of widespread service disruption. (TechCrunch report) The Verge reported on the consumer-facing outage as users lost access to Garmin Connect and related services. (The Verge report)
The absence of a detailed curve does not prove bad recovery. Garmin returned services, told investors the financial effect was not material, and later cited independent forensic analysis on data. But a service platform should be judged by evidence of degraded-mode operation, not only by the fact that it eventually came back.
What Garmin controlled
Garmin controlled several layers of the event's consequence.
First, it controlled segmentation and isolation between enterprise systems, customer-facing systems, support functions, product-update services, payment systems, developer services and aviation database workflows. The public record does not show how those layers were separated. It only shows that "some" systems were encrypted and "many" services were interrupted. A mature architecture can still require broad shutdown during investigation, but the distinction between compromise and precaution is important.
Second, Garmin controlled backup readiness and restoration order. The company did not publish backup details. CISA's ransomware guide emphasizes offline, encrypted backups, tested restoration, incident response planning, communication plans, multi-factor authentication, least privilege and recovery from clean images. (CISA StopRansomware Guide) Those are general practices, not findings about Garmin. They help define what evidence would be relevant: what data was restorable, how old it was, how restoration was validated and which services were prioritized.
Third, Garmin controlled customer communication. Its statement was reassuring but compact. It separated product function from online services, said customer data had not been indicated as accessed, and warned of backlog delays. What it did not do was provide a service-by-service status history, a product-specific workaround page in the public statement, or an aviation-specific assurance record. Customers had to piece together operational impact from status messages, support pages, media reports and experience.
Fourth, Garmin controlled the postincident lessons it chose to publish. The 10-K recognized cyberattacks as a continuing risk and disclosed the July event, but it did not describe specific remediation. That may be normal securities drafting. It is not a public resilience proof.
What customers and partners controlled
Customers were not powerless, but their control was narrower. Fitness users could keep device firmware updated when available, keep local copies where tools allowed, use alternate training logs, and avoid treating cloud sync as the only record of activity. Pilots could plan around current installed databases, verify regulatory and operational requirements, preserve alternate navigation resources and avoid waiting until the last minute to update required data. Small businesses could maintain manual support scripts, alternative status messages and customer expectations around platform outages.
Those controls matter, but they are compensating controls. They do not replace Garmin's responsibility for the systems only Garmin could restore. A user cannot restore Garmin Connect. A pilot cannot rebuild flyGarmin. A local retailer cannot answer whether Garmin Pay data was accessed. A developer cannot know whether the event affected API keys or backend queues unless Garmin tells them.
This division is the heart of platform accountability. Users can reduce dependency, but the platform operator defines the dependency in the first place. If the product's value proposition depends on cloud synchronization, account services, update subscriptions and support, the operator owns the public evidence that those functions can fail without causing avoidable harm.
Data assurance was meaningful but incomplete
Garmin's no-indication data statement matters. It covered customer data and Garmin Pay payment information in the initial notice. The 10-K later added that due diligence and independent forensic analysis gave Garmin no indication that customer data was accessed, lost or stolen. That is stronger than a first-day "we are investigating" statement.
Still, it is bounded. The public record does not identify the forensic firm, the logs reviewed, the retention limits, the time window, the specific systems examined, whether any data was staged, whether employee or supplier data was separately assessed, or whether a final customer-facing report was issued. It also does not define what "customer data" included across Garmin Connect, aviation accounts, purchases, support contacts, developer interactions and Garmin Pay.
That boundary should travel with the conclusion. The best supported wording is that Garmin said it had no indication, later based on due diligence and independent forensic analysis, that customer data was accessed, lost or stolen. The public evidence does not support a stronger claim that no data access was technically possible or that every relevant log proved a negative.
Service status is a safety and trust instrument
The incident also shows why status communication is not cosmetic. A status page or incident update tells customers what to do during uncertainty. In consumer fitness, the question may be whether to keep recording locally and wait. In aviation, the question may involve whether an update service is available before a scheduled flight. In support, the question may be whether a customer can reach a representative or should delay a repair. In developer relations, the question may be whether integration failures are caused by a partner's code or by Garmin's systems.
Garmin's public statement came after several days of outage reporting. That timing should be understood in context: an active ransomware response requires containment, forensic triage, legal review and communication discipline. Early over-specificity can be wrong. But late or vague communication transfers uncertainty to customers and partners. Reuters, ZDNet and other outlets covered the outage while Garmin was still restoring services, creating a situation in which outside reporting filled operational gaps. (ZDNet report)
The standard for future incidents should be practical. A company need not reveal sensitive technical facts during containment. It can still publish product-family status, data-risk boundaries, update workarounds, customer-support alternatives, known unavailable functions, backlog expectations and the next update time. That kind of communication reduces avoidable calls, preserves user trust and helps small counterparties answer their own customers.
The materiality statement was not the same as user harm
Garmin told investors it did not expect a material impact on operations or financial results. The 10-K later said the outage impact was not material and was not expected to have material future effects. That is a securities and financial-materiality statement. It is relevant but should not be confused with a user-impact statement.
A nonmaterial financial effect can coexist with meaningful customer disruption. A few days of unavailable synchronization may not move a public company's earnings but may disrupt training, coaching, store support, aviation planning or developer service commitments. A lack of material investor impact does not prove the outage was minor for every user. Conversely, user frustration does not prove financial materiality.
This distinction is especially important for connected-device companies. Investor filings often compress incidents into risk-factor language. Customer accountability requires more operational detail: what failed, how long, what workarounds existed, what data was delayed, what data was at risk, and what changed after recovery.
Degraded mode was different by product line
The public record is easiest to understand if the outage is separated by degraded mode. A running watch, an aviation database service, a call center and a developer integration do not fail in the same way.
For many fitness customers, degraded mode meant the device still captured a local activity but the service no longer provided ordinary synchronization, history review, social sharing and third-party movement. A user might finish a marathon training run and know the file was on the watch, but not know when it would reach Garmin Connect, whether it would sync to a coach, or whether a later upload would duplicate. The body continued doing the work; the record of the work was stuck behind a platform queue.
For aviation users, degraded mode had a different risk shape. The aircraft did not become unsafe merely because an online service was unavailable. But update timing matters in aviation. A pilot who already held current and suitable databases for the intended operation was in a different position from an operator who needed to download a new cycle, renew a subscription, install data through Garmin Aviation Database Manager, confirm an alert or reach support before dispatch. The same corporate outage therefore produced different practical consequences depending on where the user stood in an update cycle.
For marine and outdoor users, degraded mode might involve chart updates, route planning, weather-adjacent services, account access, support and device registration. A boat owner preparing for a trip or a field worker relying on GPS devices might experience a service interruption as planning friction rather than as a device failure. Again, the device-service distinction matters. Garmin could say the product still functioned; the user could still face a real continuity interruption.
For customer support, degraded mode was more circular. The outage created the need for more support while the same outage impaired support channels. Garmin's statement expressly named customer support and company communications among interrupted services. That means the recovery function was also part of the affected surface. A customer who could not sync needed information; the channel for information was itself degraded.
This is why a single uptime number would not have been enough. The correct measure is service-specific: local recording, cloud sync, payment assurance, aviation downloads, account login, call center reachability, email response, developer interfaces, support case management and backlog processing. Garmin's public record gives the categories of interruption, but not the service-by-service degraded modes. That gap limits what outside users can learn.
Developer and partner dependency widened the outage
Garmin's ecosystem includes more than individual device owners. Its developer portal presents Garmin as a platform for apps, data integrations and business relationships. (Garmin developer portal) When a platform outage occurs, developers and partners become translators. They must decide whether their own customers are seeing a bug in the partner product, a credentials problem, a device problem, or a Garmin service outage.
That translation work is often invisible in incident summaries. A third-party training app may receive user complaints when Garmin data does not arrive. A coach may have to ask athletes to send screenshots or manual files. A corporate wellness program may lose daily reporting. A repair shop may be asked to explain account access it does not control. A race organizer or event photographer may lose a route, timing or upload workflow. None of those parties controls Garmin restoration, yet they become part of the customer-facing support layer.
This is the small-business consequence of cloud service concentration. The platform operator may experience the outage as a central engineering and communications event. The small partner experiences it as many small conversations, each requiring time, trust and explanation. A few days of service loss can be operationally manageable for the platform and still materially annoying for small counterparties whose customer relationships are local and personal.
The best platform response recognizes that. It gives partners a concise incident page, allowed customer language, service categories, known workarounds, next-update times and postincident reconciliation guidance. It also states what the platform does not yet know. Silence forces partners to improvise; overconfident statements force them to retract. Garmin's public statement answered some high-level questions, but it did not publish a durable partner-facing incident account in the materials reviewed.
That matters because developers and small businesses often serve as continuity absorbers. They keep customers calm, preserve alternate records and help people resume work after the platform returns. The public record should not treat those efforts as frictionless simply because the outage was not financially material to Garmin.
Backlog integrity was the quiet technical test
Backlog processing is not just a customer-service detail. It is an integrity test. When systems return after ransomware, the company has to trust the restored environment, trust the data collected during downtime, trust the sequence in which queued information is processed and trust that customers are not harmed by duplicates, omissions or stale state.
For fitness data, backlog integrity asks whether activities recorded during the outage were eventually synchronized with correct timestamps, device identifiers, routes, metrics and privacy settings. A missed run is not a life-safety event, but it can still undermine a training record, insurance-linked wellness program, competition log or coach relationship. If customers cannot tell whether missing data is delayed or lost, support volume grows.
For aviation database services, backlog integrity asks a more formal question. If purchases, subscriptions, update requests or support cases queued during outage, customers need to know which actions completed, which need to be repeated and which might have produced stale assumptions. A database update is not merely a consumer preference. It is a controlled information product, and the customer must know whether the installed information is the one intended.
For payment and account services, backlog integrity asks whether transactions, account changes and support requests were accepted, rejected, delayed or repeated. Garmin's initial statement specifically said it had no indication that Garmin Pay customer data was accessed, lost or stolen. That was valuable assurance. The surrounding operational question was whether any payment, support or account activity needed customer action after services returned.
A more complete public postincident account would have stated whether customers needed to re-sync, re-submit, re-check purchases, re-open support cases or verify aviation downloads. It would not have needed to disclose sensitive architecture. It would have helped customers distinguish a clean recovery from a recovery that required manual confirmation.
Ransomware recovery has a confidence problem
Ransomware recovery is not finished when files decrypt or servers restart. It is finished when the operator can say why the restored environment is trustworthy. That includes malware eradication, credential rotation, persistence checks, endpoint rebuilding, backup validation, monitoring, third-party access review and staged service restoration.
Garmin's public materials do not reveal the restoration method. The company may have had strong backups, clean rebuilds, rapid forensic support and careful service validation. It may also have faced tradeoffs that are not visible. The public point is not to assume weakness; it is to identify the evidence gap.
Confidence is especially difficult when third-party reports describe a decryptor. If a decryptor was used, as reported, that does not automatically mean recovery was careless or dependent on criminals. Decryptors can be one tool in a wider recovery effort. But use of a decryptor would raise questions: which systems were decrypted rather than rebuilt, how integrity was verified afterward, whether the decryption tool itself was safe, whether backups were insufficient for certain systems, and how legal and sanctions reviews were handled if payment was involved.
Because Garmin did not publicly confirm those details, a disciplined article must keep them unanswered. Still, the unanswered state is itself useful. It shows that connected-device service accountability depends on proof of trustworthy restoration, not just public relief when a login page comes back.
What good evidence would have looked like
A fuller postincident record would have answered several questions without exposing sensitive details.
For service continuity, Garmin could have published a service-by-service timeline covering Garmin Connect, Garmin Express, Garmin Pay, flyGarmin, aviation database downloads, websites, call centers, support tickets and developer functions. It could have distinguished unavailable, degraded, restoring and backlogged states.
For ransomware recovery, Garmin could have described high-level containment and restoration categories: whether affected systems were encrypted, isolated or both; whether restoration used backups or rebuilt environments; what validation preceded reconnection; and how critical customer services were prioritized.
For aviation, Garmin could have published a specific continuity note explaining how pilots and operators should handle database-update and support interruptions, what functions were unavailable, and when database services were restored. The company did not need to publish any aircraft-sensitive information to provide that clarity.
For data assurance, Garmin could have stated the broad categories examined by independent forensics and whether findings were preliminary or final. It could also have said whether any separate employee, supplier or developer data reviews were required.
For small counterparties, Garmin could have provided a partner notice describing expected backlog behavior, support recovery, integration impact and customer messaging. That would have recognized that platform downtime radiates outward through shops, trainers, developers and service providers.
The dependency map should have been visible before the outage
Garmin's product universe makes the incident a useful warning for any company that sells hardware wrapped in recurring service. A customer buying a device may understand that online features exist, but may not understand which functions are local, which depend on account authentication, which depend on subscription databases, which depend on customer support, and which can be exported when the cloud layer is unavailable. That dependency map is part of the product promise. It should not appear for the first time during a ransomware recovery.
For fitness users, the map would distinguish activity recording, device storage, local export, cloud synchronization, third-party sharing, training-plan updates, wellness metrics, challenges, payments and support. For aviation users, it would distinguish installed avionics function, account login, database purchase, database download, database-manager operation, support response and alert communication. For small businesses, it would distinguish ordinary sales support, repair status, partner integration, customer returns and post-outage reconciliation. The public incident notice gave a broad boundary between product function and online services, but not a customer-facing dependency table that each group could use.
This matters because customers cannot prepare for dependencies they cannot see. A pilot can plan database updates earlier in a cycle if the service dependency is obvious. A coach can set expectations about delayed uploads if local export paths are known. A shop can preserve manual customer records if support-system unavailability is part of its continuity plan. A developer can design retry and status behavior if platform degradation modes are documented. None of those steps makes the customer responsible for Garmin's ransomware recovery. They simply reduce avoidable harm when a centralized service fails.
The accountability standard is therefore prospective. Connected-device companies should publish plain dependency and degraded-mode guidance for critical product families before an incident. The guidance can be high level. It does not need to expose security architecture. It should say which features work without online services, which data may queue locally, which functions require account services, which professional workflows need current online updates, and which support alternatives exist when the primary platform is unavailable. After a ransomware event, the company can then update a known dependency map instead of asking customers to infer it from scattered status messages.
Support capacity was part of recovery capacity
The outage also made customer support a recovery system. Garmin said customer support was among the interrupted services. That is easy to treat as a secondary inconvenience, but in a mixed consumer-professional platform it is a control surface. Support tells customers whether data is at risk, whether a payment function can be trusted, whether a pilot should wait for a database update, whether a device needs service, whether a developer should retry an API, and whether a backlog is normal.
If support systems are down at the same time as customer-facing applications, the company loses a major way to reduce confusion. The result is predictable: media reports, user forums, social posts, retail staff and informal support communities begin filling gaps. That can be useful, but it also increases rumor risk. A company does not have to publish forensics during containment to keep support useful. It can publish a support triage script, product-family status categories, known unavailable functions, data-risk boundaries, expected update cadence and escalation channels for aviation or safety-adjacent workflows.
Support resilience should be tested the same way backup restoration is tested. Can representatives access a clean knowledge base if ordinary systems are contained? Can call centers operate with preapproved incident scripts? Can professional users reach a priority channel? Can retail and developer partners receive the same guidance as direct customers? Can support tickets created during a manual period be reconciled after systems return? Those questions are not cosmetic. They determine whether restoration is experienced as organized recovery or as a confusing wait.
The lesson is service accountability, not panic
The Garmin outage did not prove that connected devices are unsafe or that cloud services are inherently fragile. It proved something narrower and more useful. A company that sells reliable hardware can still create centralized service dependencies that customers experience as part of the product. When ransomware interrupts those dependencies, accountability cannot stop at "the device still works."
Criminal actors caused the attack. Garmin was the victim. But Garmin also controlled the platform design, recovery evidence and public communication that determined how customers understood and absorbed the outage. Fitness users, pilots, marine users, retailers, developers and support staff did not need a full forensic report to know everything; they needed enough evidence to know what was down, what was safe, what would return, what data was delayed and what they should do meanwhile.
That is the durable accountability record. Garmin recovered and did not report material financial harm. It also left a public record too thin to evaluate segmentation, backup performance, ransom governance, service-by-service restoration or aviation-specific continuity. The next connected-device outage should not ask customers to infer those answers from silence.