Uptime Clause

TL;DR: An uptime clause sets the availability commitment for a service, defines how availability is measured, and carves out the events that do not count against the commitment. It is the single most-negotiated performance provision in cloud and SaaS contracts because a fractional-percentage difference between 99.9% and 99.99% represents a forty-fold change in allowable downtime. A well-drafted uptime clause nails down the measurement window, the monitoring methodology, the excluded events, the reporting cadence, and the connection to the service credits that turn a missed commitment into a real remedy.

‍

What Is an Uptime Clause?

An uptime clause is the core performance commitment in a service level agreement that specifies the percentage of time a service will be available to the customer. The clause defines a numeric threshold (commonly 99.9% or 99.99%), the measurement window (typically monthly), the methodology used to calculate availability, and the events that are excluded from the availability calculation. In a typical SaaS or cloud contract, the uptime clause is paired with a service credits clause that provides the financial remedy when the commitment is missed.

The numeric threshold is the headline figure, but the measurement methodology is where most disputes occur. Availability can be measured by pinging a health endpoint every minute, by monitoring transactional success rates, by counting seconds of total outage versus partial degradation, or by calculating availability per region versus globally. A 99.9% commitment measured by health-check pings is very different from a 99.9% commitment measured by successful completion of customer API calls, and the difference between the two can determine whether a real outage produces a credit or is absorbed quietly into the rounding.

Uptime commitments became a staple of commercial technology contracts with the rise of managed hosting in the late 1990s and early 2000s, and the enterprise SaaS wave of the 2010s turned them into a universal feature. The hyperscale cloud providers publish standardized uptime commitments on their public websites (AWS EC2 SLA, Azure SLA, Google Cloud SLA), and those published figures have become the market-standard reference points for negotiated enterprise deals. The commitment numbers themselves are often expressed using the shorthand "number of nines" convention, where 99% uptime is "two nines," 99.9% is "three nines," 99.99% is "four nines," and 99.999% is "five nines," each representing approximately a tenfold reduction in allowable downtime.

The economic stakes in uptime negotiations are substantial. For a customer running mission-critical operations on a vendor's platform, the difference between four nines and three nines can represent hours of lost productivity or transaction revenue each month. For a vendor, a five-nines commitment effectively requires investment in active-active multi-region architectures, sophisticated deployment practices, and extensive observability tooling that many providers cannot economically sustain at mid-market pricing.

‍

Why It Matters

• Numeric Thresholds Have Huge Downtime Differences: A 99.0% commitment allows approximately 7 hours 18 minutes of downtime per month; 99.9% allows 43.2 minutes; 99.99% allows 4.32 minutes; 99.999% allows 25.9 seconds. Each additional nine reduces allowable downtime by roughly a factor of ten, which is why vendors resist adding nines even when customers perceive the change as minor.
• Measurement Methodology Determines Real Coverage: Two identical numeric commitments can produce dramatically different outcomes depending on whether availability is measured by external ping, internal health check, transactional success rate, or customer-experienced outcome. The clause that only appears strict on the number but weak on the methodology often produces no credits even when the customer experiences real disruption.
• Measurement Window Shapes Incentives: A commitment measured monthly absorbs a longer outage in one month by "averaging down" across future periods; a commitment measured on a rolling basis prevents recovery from a bad month. Annual or quarterly windows let vendors spread out-of-spec months and reduce the frequency of credit events.
• Exclusions Define the Boundary of Control: The catalogue of excluded events (scheduled maintenance, emergency patches, force majeure, customer-caused issues, third-party network failures) determines whether the commitment covers true vendor failures or carves out so much that the clause becomes ornamental. Maintenance windows in particular are often the largest exclusion category.
• Reporting Obligations Create the Evidentiary Record: A commitment with no reporting obligation places the entire monitoring burden on the customer. Vendors that issue monthly availability reports with raw measurement data convert the clause into a practical compliance tool. Without reporting, even a strong commitment becomes hard to enforce.
• Regulatory and Insurance Implications: For regulated industries, uptime commitments feed into operational risk frameworks (FFIEC, OCC bulletins on third-party risk, EBA Guidelines on Outsourcing, EU DORA). Inadequate uptime or unclear exclusions can create downstream regulatory exposure for the customer.

‍

Key Elements of a Well-Drafted Uptime Clause

1. Defined Availability Percentage: State the exact percentage commitment (for example, 99.95%) rather than a qualitative phrase like "commercially reasonable availability." Include the measurement window explicitly (calendar month, rolling thirty-day period, calendar quarter).
2. Measurement Methodology: Specify the exact method used to measure availability. A best-practice formulation: "Availability is calculated as (Total Measurement Minutes - Unavailable Minutes) / Total Measurement Minutes, expressed as a percentage." Define "Unavailable Minutes" by reference to a specific test (for example, failure of documented health check from two or more geographically separated monitoring locations during any one-minute interval).
3. Scope of Covered Services: Identify which services, features, or components are covered. In multi-service platforms, availability commitments often apply per module rather than to the entire product. State whether beta or preview features are excluded, and whether the commitment covers core APIs only or includes the web application, mobile clients, and administrative interfaces.
4. Scheduled Maintenance Windows: Define the maintenance window (for example, Saturdays 0200-0600 UTC), the notice period required (typically seven calendar days), the maximum maintenance time that may be excluded per month (often four to eight hours), and the frequency limitation. Emergency maintenance should have its own tighter specification with a reasonable notice qualifier.
5. Enumerated Exclusions: List all excluded events specifically. Standard categories include scheduled maintenance within the defined window, emergency maintenance with reasonable notice, force majeure as defined in the general force majeure clause, customer-caused outages (including customer misconfiguration, customer-side network failures, and customer's third-party integrations), and third-party infrastructure failures outside the vendor's reasonable control. Avoid open-ended catch-all language.
6. Monitoring and Reporting: Specify the vendor's obligation to monitor availability, the tooling or methodology, and the reporting cadence. Best practice: a monthly SLA report delivered within fifteen days of month-end, containing the calculated availability percentage, the underlying measurement data, an incident log, and root-cause summaries for any credit-generating events.
7. Connection to Service Credits: Reference the service credits clause for the financial remedy, or incorporate the credit schedule directly. Make clear that credits accrue only to covered services and only for breaches of the defined availability percentage measured by the specified methodology.
8. Definitions That Prevent Interpretive Gaps: Define every operative term ("Available," "Unavailable," "Downtime," "Outage," "Measurement Period," "Incident," "Covered Service") in a way that prevents post-hoc argument over what counts. Ambiguity favors the vendor, so precision favors the customer.

‍

Market Position & Benchmarks

Where Does Your Clause Fall?

• Customer-Favorable: Availability of 99.95% or higher, measured monthly by transactional success rate from customer-experienced vantage points. Narrow exclusion list covering only pre-announced scheduled maintenance within a capped window (4 hours per month), force majeure, and customer-caused issues defined specifically. Monthly SLA reports delivered within ten business days of month-end, with raw measurement data. No exclusion for third-party infrastructure unless the vendor can show the failure was outside any reasonable control and could not be mitigated by architectural redundancy.
• Market Standard: Availability of 99.9% measured monthly by health-check or API success rate, with the measurement methodology documented. Exclusions include scheduled maintenance within a reasonable window (typically 4-8 hours per month with seven-day notice), emergency maintenance with reasonable notice, force majeure, customer-caused outages, and third-party network or infrastructure failures. Monthly SLA reports delivered within 15-30 days of month-end. Availability measured per region or service; no cross-region aggregation unless explicitly contracted.
• Vendor-Favorable: Availability of 99.5% to 99.9% measured quarterly or annually. Measurement based on ping-type health checks from vendor-controlled monitoring points. Broad exclusion list including any scheduled maintenance without defined windows, all third-party issues, and catch-all language for "events outside Vendor's reasonable control." Limited or no reporting obligation; customer must independently monitor and request data. Availability calculated as a global average that absorbs regional outages.

Market Data

• The canonical availability-to-downtime table is: 99% = 7h 18m per month; 99.9% = 43m 12s per month; 99.95% = 21m 36s per month; 99.99% = 4m 19s per month; 99.999% = 25.9 seconds per month; 99.9999% = 2.59 seconds per month.
• Per the AWS EC2 SLA (v2024.09), AWS commits to 99.99% Monthly Uptime Percentage for a Multi-AZ deployment and 99.5% for a Single-AZ deployment, measured via Amazon's internal monitoring across AWS regions.
• Microsoft Azure publishes per-service SLAs ranging from 99.9% for most single-region services to 99.99% for zone-redundant configurations and 99.995% for certain cosmos-scale database tiers.
• Gartner's 2024 enterprise SaaS benchmark reported that 72% of negotiated enterprise agreements secured at least 99.9% uptime, 28% secured 99.95% or higher, and that the single most common vendor concession during negotiation was improvement of the uptime commitment from 99.9% to 99.95%.
• A 2023 ACC CLO survey found that 81% of customer counsel identify uptime commitments and exclusion scope as among the top three negotiated items in new SaaS contracts, alongside limitation of liability and data protection.
• The Uptime Institute's Tier Standard Topology defines four data center tiers with effective availability commitments of 99.671% (Tier I), 99.749% (Tier II), 99.982% (Tier III), and 99.995% (Tier IV), which are frequently referenced as infrastructure-layer benchmarks for contractual uptime commitments.

Sample Language by Position

Customer-Favorable: "Vendor commits that the Service shall be Available for at least 99.95% of each calendar month (the 'Availability Commitment'), measured as: Availability = (Total Measurement Minutes - Unavailable Minutes) / Total Measurement Minutes. 'Unavailable' means, for any one-minute interval, that Vendor's health endpoint fails to respond successfully to at least two of three geographically distributed monitoring probes operated by an independent third-party monitoring service. Vendor shall deliver a monthly Availability Report within ten (10) business days of the end of each calendar month, including the calculated Availability Percentage, the underlying minute-by-minute measurement log, and a root-cause summary for any minute classified as Unavailable. Scheduled Maintenance shall not exceed four (4) hours per calendar month in aggregate, shall occur only during the Maintenance Window of 0200-0600 UTC on Sunday, and shall be announced at least seven (7) days in advance."

Market Standard: "Vendor will use commercially reasonable efforts to make the Service Available at least 99.9% of the time during each calendar month, excluding Scheduled Maintenance and Excluded Events. 'Monthly Uptime Percentage' means the total minutes in the calendar month less Unavailable Minutes, divided by the total minutes in the calendar month. 'Unavailable' means the Service is not accessible to Customer as measured by Vendor's monitoring systems. 'Scheduled Maintenance' means maintenance performed during the Maintenance Window (Saturdays 0200-0600 UTC) for which Vendor has provided at least seven (7) days advance notice. 'Excluded Events' means: (a) emergency maintenance; (b) events of Force Majeure; (c) acts or omissions of Customer or Customer's users; (d) failures of Customer's equipment, software, or third-party services; and (e) attacks on the Service that Vendor could not reasonably prevent."

Vendor-Favorable: "Vendor shall use commercially reasonable efforts to make the Service substantially available, targeting availability of 99.5% calculated on a rolling quarterly basis. Availability means the percentage of time during the measurement quarter that the Service is generally available to users, as determined by Vendor's internal monitoring in its reasonable discretion. The following events shall not be included in the calculation of Unavailability: (i) any Scheduled Maintenance; (ii) any event outside Vendor's reasonable control, including but not limited to force majeure, internet congestion, third-party service or infrastructure issues, distributed denial of service attacks, or actions of governmental authorities; (iii) Customer's actions or inactions; (iv) Beta, Preview, or Early Access features; and (v) any issue with Customer's equipment, network connection, software, or third-party applications."

‍

Example Clause Language

Enterprise SaaS agreement with 99.95% monthly uptime, independent monitoring, and detailed exclusions:

Enterprise SaaS Example: "Vendor commits to Monthly Uptime Percentage of at least 99.95% for the Core Service, defined as the production REST API and web application accessible at the URLs set forth on Schedule A. Monthly Uptime Percentage shall be calculated as (Total Minutes in Measurement Period - Downtime Minutes) / Total Minutes in Measurement Period, expressed as a percentage. A minute shall be a Downtime Minute if, during that minute, more than one percent (1%) of valid API requests return 5xx errors or fail to respond within thirty (30) seconds, as measured by the monitoring infrastructure maintained by Vendor and supplemented by readings from a third-party external monitoring service retained by Customer at Customer's expense. Downtime Minutes shall exclude: (a) Scheduled Maintenance performed during the Maintenance Window (Saturday 0200-0600 UTC) announced at least seven (7) calendar days in advance, subject to an aggregate cap of four (4) hours per calendar month; (b) Emergency Maintenance with such notice as is reasonably practicable; (c) force majeure events as defined in Section [X]; and (d) Downtime resulting from Customer's actions contrary to the Documentation. Vendor shall provide a Monthly SLA Report within ten (10) business days after the end of each calendar month."

Multi-region cloud infrastructure agreement with region-level calculation and zone-redundant tier:

Cloud Infrastructure Example: "For Services deployed in a Multi-Region Configuration, Vendor commits to 99.99% Monthly Uptime per Region, measured independently for each Region in which Customer has active workloads. The Multi-Region Availability Commitment applies only to workloads configured to automatically fail over between Regions pursuant to the Documentation. For Services deployed in a Single-Region Configuration, Vendor commits to 99.9% Monthly Uptime for that Region. Any inconsistency between the Multi-Region and Single-Region commitments shall be resolved in favor of the higher commitment applicable to the actual Customer deployment."

Managed services agreement with split availability across tiers:

Managed Services Example: "Provider commits to the following availability targets for Services categorized by Priority Tier: Priority 1 Services (business-critical) - 99.95% Monthly Availability; Priority 2 Services (important) - 99.9% Monthly Availability; Priority 3 Services (standard) - 99.5% Monthly Availability. The Priority Tier for each Service is set forth on Schedule B and may be updated by mutual written agreement. Availability shall be measured by the managed monitoring toolset specified in the Statement of Work."

‍

Common Contract Types

• SaaS Subscription Agreements: The most common setting for uptime commitments. Enterprise SaaS contracts typically feature 99.9% or 99.95% monthly uptime, with credit schedules in the service credits clause.
• Cloud Infrastructure (IaaS and PaaS) Agreements: Uptime commitments vary by service; core compute, storage, and network often reach 99.99% in multi-region configurations. Typically published as standardized SLAs on the provider's website and referenced by enterprise agreement.
• Managed Services and Outsourcing Contracts: Uptime commitments per service tier or application, often linked to priority-based credit tables and to chronic-failure termination rights.
• Telecommunications and Network Services: Circuit availability, packet loss, and latency commitments. Often expressed as percentages of circuit-time availability with defined per-event Mean Time to Repair targets.
• Hosting and Colocation Agreements: Data center power availability (commonly 99.982% for Uptime Institute Tier III), cooling, and network availability. Often expressed as downtime minutes per year rather than percentage.
• Payment Processing and Financial Services APIs: Transaction authorization availability and API uptime. Failure tolerances are typically tight because of the business impact of even brief outages.
• Public Sector and FedRAMP Cloud Agreements: Federal and state government cloud contracts specify uptime consistent with federal baseline requirements, often 99.95% or higher for mission systems.
• Healthcare IT and Clinical Systems Agreements: Uptime commitments for EHR, PACS, and clinical decision support systems. Often paired with data integrity and disaster recovery commitments given patient safety implications.

‍

Negotiation Playbook

Key Drafting Notes

• Pin Down the Methodology Before the Number: The measurement methodology often has more dollar impact than the headline percentage. A 99.9% commitment measured by health-check pings from vendor-controlled probes is weaker than a 99.5% commitment measured by transactional success from customer-facing vantage points. Negotiate methodology first, then argue about the number.
• Benchmark Against the Public SLA: Most vendors publish standardized uptime commitments on their websites. A customer accepting a lower uptime than the vendor's public SLA has lost the negotiation before it started. Use the public SLA as the floor and negotiate upward from there.
• Cap the Maintenance Window: Scheduled maintenance is often the largest exclusion. Cap the maintenance time at a defined number of hours per month (typically four to eight), require advance notice (typically seven days), restrict maintenance to off-peak hours, and require the vendor to make commercially reasonable efforts to perform maintenance without service interruption.
• Align the Reporting Cadence With the Claim Window: The reporting cadence should give the customer enough time to validate the vendor's availability calculation and submit any credit claims. Require reports within 10-15 business days of month-end and align the credit claim deadline to the report issuance date (for example, 60 days from issuance).
• Specify Covered Services: In multi-module platforms, the uptime commitment may apply only to certain services. Negotiate coverage for all services the customer actually depends on, or negotiate differentiated uptime commitments keyed to each service's business priority.
• Connect Chronic Failure to Termination: An uptime clause without a termination remedy traps the customer in a failing relationship. Pair the availability commitment with a chronic-failure termination right (typically two or more credit-generating events in a rolling 12-month period, or any single outage exceeding a defined duration).

Common Pitfalls

• Availability Measured Only From Vendor Vantage Points: Vendors that measure availability only from inside their own networks can miss outages visible to customers. Require at least supplemental measurement from external vantage points, ideally run by an independent third-party monitoring service.
• Undefined Maintenance Windows: Clauses that say "Vendor may perform maintenance from time to time with reasonable notice" give vendors effectively unlimited downtime. Define the window specifically and cap the total maintenance time per month.
• Catch-All Exclusion Language: Broad language like "any event outside Vendor's reasonable control" lets vendors classify real operational failures as excluded events. Enumerate exclusions specifically and require any catch-all language to be qualified by a good-faith and commercial-reasonableness standard.
• No Reporting Obligation: An uptime commitment without a reporting obligation is essentially unenforceable. The customer cannot credibly assert a breach without the vendor's underlying measurement data. Always require a monthly SLA report.
• Annual or Quarterly Measurement Windows: Measurement windows longer than a month let vendors absorb a bad month by averaging against good months. Monthly measurement produces tighter accountability and more frequent credit events.
• Availability Calculated Across All Users: Some clauses measure availability as a percentage of users successfully served, which can mask outages affecting a single region, tenant, or customer segment. Require availability to be measured per region, per service, and per tenant where appropriate.

‍

Jurisdiction Notes

• U.S.: Uptime commitments are enforced as ordinary contract terms under state law (most commonly New York, Delaware, or California in enterprise deals). Courts generally enforce negotiated SLA provisions between sophisticated commercial parties, including limitations on remedies and sole-and-exclusive-remedy provisions tied to service credits (ASV Restaurants, Inc. v. Burger King Corp., 2015 WL 3796323 (S.D.N.Y. 2015); Navisite, Inc. v. Bridgefield Casualty Insurance, 2013 WL 5435322 (D. Mass.)). The UCC does not directly govern pure service contracts, but mixed hardware-and-service arrangements can draw in UCC Article 2 through the predominant-purpose test. UCITA, adopted in Maryland and Virginia only, applies to software licensing and affects enforceability of certain remedy limitations. For regulated industries, federal bank regulators (OCC Bulletin 2013-29, FRB SR 13-19, FFIEC Outsourcing Technology Services Booklet) expect financial institutions to require contractual uptime and resilience commitments from service providers as part of third-party risk management.
• U.K.: English law treats uptime commitments as straightforward contract terms. The Unfair Contract Terms Act 1977 can apply to exclusions and limitations in B2B contracts where one party deals on the other's standard terms, but negotiated commercial uptime clauses between sophisticated parties are generally enforced as written (Watford Electronics Ltd v. Sanderson CFL Ltd [2001] EWCA Civ 317). The penalty doctrine as reformulated in Cavendish Square Holding BV v. Makdessi [2015] UKSC 67 asks whether a secondary obligation (such as a remedy on breach) imposes a detriment out of all proportion to any legitimate interest; service credits tied to missed uptime commitments are very unlikely to fail this test. Under DORA's broader EU framework and UK FCA operational resilience rules (SYSC 15A), regulated firms must secure contractual availability commitments from critical third-party providers.
• Other: In the EU, the Digital Operational Resilience Act (DORA, Regulation (EU) 2022/2554, fully applicable from 17 January 2025) imposes mandatory contractual provisions for ICT services provided to financial entities, including availability and resilience commitments. The EBA Guidelines on Outsourcing Arrangements (EBA/GL/2019/02) set similar expectations for banks and payment institutions. For international customers, CISG Articles 30-34 address delivery and performance in cross-border sales of goods but do not directly govern availability of cloud services. Singapore, Hong Kong, and Australian commercial courts generally enforce negotiated uptime commitments between sophisticated parties similarly to U.S. and U.K. practice.

‍

Related Clauses

• SLA Clause - The parent framework; the uptime clause is typically the headline metric inside the broader SLA.
• Service Credits Clause - The remedy mechanism that attaches financial consequences to missed uptime commitments.
• Force Majeure - The principal exclusion category in any uptime clause; the scope of force majeure directly affects when downtime counts against the commitment.
• Limitation of Liability - Interacts with the sole-and-exclusive-remedy language that typically ties uptime failures to service credits only.
• Termination for Cause - The chronic-failure termination right tied to persistent uptime breaches is typically structured as a termination-for-cause event.
• Audit Clause - Enables customer verification of vendor availability measurements and the underlying data used to calculate uptime.
• Data Breach Notification Clause - Companion operational obligation; availability failures often correlate with incidents that also trigger breach notification duties.

‍

This glossary entry is provided for informational and educational purposes only. It does not constitute legal advice, and no attorney-client relationship is formed by reading this content. Consult qualified legal counsel for advice on specific contract matters.