An outage is a starting fact, not a liability conclusion
A service availability failure can be relevant to product liability when it contributes to an unsafe product condition and qualifying damage. An outage alone does not establish either. Directive (EU) 2024/2853 requires an assessment of the product, defectiveness, harm and causation, together with responsibility and scope. Many ordinary interruptions are principally contractual or service-quality issues.
The SaaS and cloud services framework distinguishes software products from related services and infrastructure. Begin by identifying what became unavailable. A public status page may report an entire platform incident even though only a monitoring screen failed for the affected user. Conversely, a platform may appear operational while a small group of devices loses an essential control function. The specific function matters more than the headline uptime percentage.
Identify the dependency and failure mode
Record whether the product lost its primary function, a secondary feature or only visibility into a function that continued locally. A dashboard can stop refreshing while a device remains safely controlled. Another device can keep displaying a normal status while remote commands have stopped. Establish what happened at the product, not merely what the cloud service reported about itself.
Distinguish a total outage from delayed, intermittent or incomplete responses. A delayed command can be more dangerous than no command if the receiving product accepts it after conditions have changed. Retries can duplicate instructions. Recovery can release queued work all at once. These are hypotheses to test using event records; they should not be asserted as the cause merely because the architecture could permit them.
Separate internet access from related services
The related-service definition turns on product dependence and integration. Recital 17 excludes internet access services from related-service treatment. General broadband connectivity therefore needs to be distinguished from a cloud controller or other product-specific digital service. A household router, access provider and application backend can each produce a similar symptom on a device while raising different classification questions.
The same recital recognises that a product relying on internet access can be defective if it fails to maintain safety after connectivity is lost. Excluding the access service does not establish that the product's own fallback behaviour was safe. Investigate what a reasonably foreseeable disconnection caused the product to do, including its local limits, warning behaviour and recovery sequence, without assuming that continuous connectivity was guaranteed.
Evaluate fallback behaviour as a safety question
Article 7 assesses safety in all the circumstances. A product designed to prevent damage receives particular attention to failure to fulfil that purpose. For an alarm, evidence about lost notification paths and local warning capability may therefore matter. For an ordinary convenience feature, the loss might have a different safety significance. A generic availability target cannot replace a product-specific safety assessment.
Consider a domestic controller that retains the last instruction during an outage. Retention might be safe for some functions and unsafe for others. The assessment needs operating conditions, duration, foreseeable use and the way users were informed. It should also consider whether a warning reached anyone able to act. A log showing that the server generated a warning does not prove that the device displayed it or the user received it.
Distinguish temporary inaccessibility from covered damage
Article 6 includes death or personal injury, certain property damage and destruction or corruption of data not used for professional purposes. Temporary inability to reach intact files is not automatically data destruction or corruption. Subscriptions paid during downtime, missed opportunities and standalone lost sales are not additional damage categories. Material losses consequential on covered damage present a different question from pure economic loss alone.
Property used exclusively professionally and the defective product itself fall within exclusions, and damage to an integrated product from a defective component has a further exclusion. The classification of the damaged interest matters as much as the outage's duration. An interruption affecting an industrial production line should not be described as automatically compensable under this Directive merely because the financial consequences are severe.
Reconstruct the sequence before allocating responsibility
Compare service logs, device events, network information and evidence of the harm. Record time zones, clock drift and known gaps. The cloud platform's incident start time may reflect when monitoring detected a problem rather than when the relevant function stopped. A customer complaint time may be later still. Preserve the different times rather than forcing them into an apparently exact chronology unsupported by the records.
Identify who supplied and authorised the relevant dependency. A cloud operator might be the related-service provider, a software manufacturer or an infrastructure contractor, depending on the actual role. Article 8 responsibility cannot be allocated solely from a list of suppliers. Where a product failed unsafely during another party's outage, both the initiating event and the product response need separate investigation.
Preserve recovery evidence without treating it as proof
Recovery records can show whether restarting a service restored a function, whether local intervention was required and whether delayed actions followed. Preserve original incident data safely and record changes made during mitigation. A later successful test does not disprove an intermittent fault, while service restoration does not by itself prove that the outage caused the damage claimed.
Article 10 provides the starting proof requirements and conditional, rebuttable presumptions. National procedure and the corrected product-date scope still require assessment. A useful outage account therefore identifies the missing function, its safety consequence, the covered damage alleged and the supported causal steps. That structure explains why some service failures may warrant product liability investigation while many ordinary periods of downtime require different legal remedies.
Records that help the review
Use the following as a practical starting point. Select and preserve records appropriate to the product, incident and applicable procedure.
- Incident-time software, device and deployment identifiers
- Functional dependency and authorisation records
- Original logs with timestamps and recorded limitations
Independent educational information at EU Directive level. National implementing law, product timing and procedure require separate review.
Primary sources and legal scope
This page explains the EU Directive framework. Check national implementing law, the corrected temporal scope and relevant procedure before applying it to a case.
- Directive (EU) 2024/2853, consolidated text: Articles 4, 6, 7, 8, 10, 11 ↗
- Official Journal corrigendum, 7 May 2026: Article 2(1) ↗
Source register: corrected scope verified 16 October 2026. Article references identify the legal basis. No qualified legal review or national implementation status is claimed.