Not all downtime is your fault. A customer misconfigures their integration and takes themselves offline. A third-party payment processor goes down. You take a two-hour maintenance window on a Sunday night with two weeks notice. AWS has a regional outage.
None of these are failures of your service. But without well-drafted exclusions, all of them count against your uptime commitment and potentially trigger credits you don’t owe.
Exclusions are the section of your SLA that defines what doesn’t count as downtime. They’re negotiated hard because customers want narrow exclusions and providers want broad ones. The goal is exclusions that are specific enough to be enforceable, honest enough to be defensible, and broad enough to cover the scenarios genuinely outside your control.
Scheduled Maintenance
Planned maintenance is the most straightforward exclusion, and the one most likely to be accepted by enterprise customers without pushback. The logic is simple: if you’ve told them in advance the service will be unavailable, they can plan around it. That’s materially different from unexpected downtime.
The exclusion needs two elements to be enforceable: a notice requirement and a time window. A common structure is maintenance excluded from uptime calculations provided you give at least 48 to 72 hours advance notice, during a defined low-traffic window such as weekends or overnight hours in a specified timezone.
The notice requirement matters. A maintenance exclusion without a notice requirement lets you take the service down at any time and call it scheduled. Enterprise buyers will not accept this, and they’re right not to. The notice requirement is the consideration that makes the exclusion legitimate.
Some customers will push for advance approval rights rather than just notice. The provider-friendly position is notice only, with a reasonable window. If your customer wants to be able to veto maintenance windows, you’ve effectively given them control over your deployment schedule.
Force Majeure
Force majeure covers events outside anyone’s reasonable control: natural disasters, government actions, war, widespread internet infrastructure failures. The exclusion is standard in commercial contracts and rarely negotiated heavily in SLAs because the scenarios it covers are genuinely extreme.
The language matters more than founders typically realize. “Acts of God” is vague and jurisdiction-dependent. A well-drafted force majeure exclusion lists specific categories: natural disasters, acts of government, civil unrest, widespread telecommunications failures, and similar events beyond the reasonable control of either party.
One category worth addressing explicitly: cloud provider outages. A major AWS or GCP regional failure is not your fault, but it may not qualify as force majeure under a strict reading of the term. The cleaner approach is to handle cloud provider outages as a separate exclusion category, discussed below, rather than relying on force majeure to cover them.
Customer-Caused Issues
If a customer’s actions cause or contribute to a service disruption, that downtime should not count against your uptime commitment. Standard scenarios include misconfigured API integrations that generate excessive load, customers exceeding documented rate limits, customers modifying configuration settings in ways that break their own access, and customers using the service in ways that violate your acceptable use policy.
The drafting challenge is specificity. A blanket exclusion for “customer actions” is too broad and won’t survive negotiation. The exclusion should be tied to actions that violate your documentation, your acceptable use policy, or your usage guidelines, and should require that the customer’s action was a proximate cause of the outage.
This exclusion also requires that your documentation is accurate and accessible. If you’re excluding downtime caused by customers exceeding rate limits, your rate limits need to be documented somewhere the customer can find them. Exclusions that rely on undocumented requirements are difficult to enforce.
Third-Party Service Outages
Your product depends on services you don’t control. Cloud infrastructure, DNS providers, payment processors, email delivery services, identity providers. When those services go down, your service may go down with them.
The question is how broadly to draft this exclusion. The provider-friendly position excludes all downtime attributable to third-party services outside your reasonable control. The customer-friendly position limits this exclusion to infrastructure providers you’ve disclosed, on the theory that your architectural choices are your responsibility.
The reasonable middle ground is an exclusion tied to disclosed dependencies. Your SLA or an associated document should list the third-party services your product depends on for core functionality. Outages of those services, where the outage is publicly documented by the provider, are excluded from your uptime calculation. This gives customers visibility into your dependency stack while excluding outages you genuinely couldn’t prevent.
One important nuance: if a third-party outage is foreseeable and you’ve taken no steps to mitigate it, the exclusion is weaker. A product with no redundancy for a single DNS provider has made an architectural choice. The exclusion doesn’t absolve you of that choice, but it does allocate the contractual risk appropriately for events outside your control at the time of the outage.
Beta and Preview Features
Features you’ve designated as beta, preview, or early access should be excluded from your SLA commitments entirely. These features are, by definition, not production-ready, and including them in your uptime calculations creates obligations that aren’t matched by your development and testing standards for those features.
The exclusion should be tied to a clear designation mechanism: features labeled as beta or preview in your product, your documentation, or your release notes are not covered by the SLA. This gives you flexibility to ship and iterate on new functionality without extending your reliability commitments to work in progress.
Enterprise customers will sometimes push back on this exclusion if they’re relying on a beta feature for core workflows. The right answer is to graduate the feature out of beta before making it a contractual dependency, not to extend SLA coverage to features that aren’t ready for it.
Security Incidents and Cyber Attacks
Cyber attacks are a foreseeable operational risk for every SaaS company, which means they don’t belong in force majeure. Force majeure covers genuinely unforeseeable events outside anyone’s control. A DDoS attack or a ransomware incident is neither unforeseeable nor, in many cases, unpreventable. Treating attacks as force majeure signals to enterprise buyers that you haven’t thought carefully about security as an uptime risk.
The better approach is a dedicated exclusion for security incidents, separate from force majeure, scoped by causation rather than event type.
The causation distinction is the key: if an attack succeeded because you failed to patch a known vulnerability, left default credentials in place, or otherwise fell short of the security commitments in your DPA, the exclusion is weak and you probably shouldn’t claim it. If the attack was a novel vector, a zero-day exploit, or a volumetric DDoS that exceeded industry-standard mitigation capabilities despite reasonable precautions on your part, the exclusion is defensible.
A well-drafted security incident exclusion covers downtime resulting from a security event where you can demonstrate that you had implemented reasonable security measures consistent with your DPA commitments and the incident was not attributable to your failure to maintain those measures. This framing does several things. It ties the exclusion to your actual security posture rather than giving you a blanket carve-out for any attack. It creates an incentive to maintain the security commitments in your DPA, because those commitments become your SLA defense as well. And it’s honest: security failures that stem from your own negligence shouldn’t be excluded from your uptime calculation.
DDoS attacks warrant specific treatment. Volumetric attacks that exceed your mitigation capacity are closer to force majeure in character and are generally accepted as a standalone exclusion by enterprise buyers, provided you have baseline DDoS mitigation in place. Having no DDoS protection and going down under a moderate-volume flood is a different situation from having a reputable mitigation provider and being hit by an attack that exceeds their published capacity thresholds. The exclusion should require that you have a named mitigation solution in place, which also ties back to your DPA security schedule.
The practical upshot: your SLA security incident exclusion and your DPA security schedule need to be consistent. If your DPA commits to specific security measures, those same measures are implicitly the threshold for determining whether a security-related outage is excludable. Drafting them in isolation from each other creates contradictions that enterprise legal teams will find.
Exclusions that are too vague don’t hold up in disputes. A few principles that make exclusions work:
Specificity over breadth. “Events outside our control” is not a useful exclusion. A list of specific categories with defined characteristics is. The more precisely you define the exclusion, the easier it is to apply and the harder it is to dispute.
Documentation requirements. Where an exclusion depends on external evidence, specify what that evidence looks like. For cloud provider outages, a public status page entry from the provider. For customer-caused issues, your support ticket records and log data. This gives you a factual basis for applying the exclusion rather than a he-said-she-said dispute.
Proportionality. Exclusions should cover scenarios genuinely outside your control. An exclusion drafted so broadly that it covers your own operational failures will not be accepted in negotiation and will not be enforced if disputed. The goal is accurate risk allocation, not maximum protection regardless of fault.
Notice for scheduled events. Any exclusion tied to a planned event requires a notice obligation. Maintenance windows, planned migrations, and similar events should have defined notice periods that you’re actually required to honor.
The Negotiation Dynamic
Customers negotiate exclusions by trying to narrow them. The common pushbacks: requiring that cloud provider outages be listed specifically rather than covered categorically, limiting the force majeure exclusion to extreme events only, and requiring that customer-caused exclusions be documented in a support ticket before being applied.
Most of these are reasonable asks. A customer who wants you to list your cloud infrastructure dependencies is asking for transparency about your architecture, not asking you to accept liability for AWS going down. Agreeing to list dependencies while holding the exclusion for those dependencies is usually the right trade.
Where to hold firm: the maintenance exclusion with notice, the beta feature exclusion, and the customer-caused exclusion tied to documented usage policies. These are legitimate protections that reflect how your service actually works, and softening them exposes you to credits you genuinely don’t owe.
No Boiler provides self-service legal document generation and educational content. This material and our service is not a substitute for legal advice. Please have a qualified attorney review any documents before relying on them. No Boiler is not a law firm, and communications with us do not create an attorney-client relationship or carry any expectation of confidentiality. Use of our platform and content is governed by our Terms of Service and Privacy Policy.