Downtime Clauses in SaaS Agreements for UK Businesses: What to Include

If your business relies on software to trade, serve customers or run internal operations, downtime is not a minor technical issue. It can mean missed orders, failed customer support, payroll delays, lost data access and serious reputational damage. Yet many UK businesses still sign SaaS contracts without reading the downtime wording closely. Common mistakes include accepting vague uptime promises with no remedy, relying on a sales promise that never makes it into the contract, and overlooking broad exclusions that let the provider avoid responsibility when things go wrong.

The right downtime clause does more than state a percentage. It should spell out what counts as downtime, how incidents are measured, what support response times apply, what service credits or termination rights you get, and where the provider's liability stops. This guide explains what downtime clauses in SaaS agreements mean for UK businesses, the legal issues to check before you sign, and the common drafting traps that founders and SMEs often miss when they accept a provider's standard terms.

Overview

Downtime clauses set the commercial and legal rules for service outages in a SaaS agreement. For UK businesses, the practical question is whether the clause gives you a realistic remedy when the software is unavailable, or only a headline promise that is difficult to enforce.

A useful clause should match the way your business actually uses the platform, especially if you depend on it for customer transactions, finance, operations or compliance records.

• Define exactly what counts as downtime, degradation and scheduled maintenance
• Check the uptime commitment, measurement period and reporting method
• Make sure support response and fix times are stated clearly
• Review service credits, refund rights and any right to terminate for repeated outages
• Read exclusions carefully, including maintenance windows, third party failures and customer-caused issues
• Check liability caps, data loss wording and disaster recovery obligations
• Confirm whether the contract reflects any pre-contract promises about resilience or availability

What Downtime Clauses in SaaS Agreements Means For UK Businesses

Downtime clauses decide what happens when a cloud software provider fails to keep the service available. Before you sign a contract, you need to know whether the clause protects your business in a meaningful way or simply limits the provider's exposure.

In most SaaS agreements, downtime wording sits across several sections, not just one. You may find relevant terms in the service level schedule, support policy, limitation of liability clause, termination clause, data processing terms and force majeure wording.

What the clause is trying to do

At a basic level, a downtime clause allocates risk. The provider wants to define when an outage counts, narrow the circumstances in which it is responsible and limit the remedy to service credits. The customer usually wants continuity, faster support, financial relief and a way out if outages keep happening.

This matters because the commercial impact of downtime varies hugely. A short outage in an internal collaboration tool may be inconvenient. A short outage in your payment gateway, ecommerce platform, booking system or CRM during peak trading hours may be far more serious.

Why UK businesses should care

For a UK startup or SME, standard SaaS terms often assume the provider holds the bargaining power. That can leave you with broad disclaimers, very low liability caps and weak service commitments, particularly if you accept click-through terms or buy quickly without a contract review.

The legal position also depends on the wider contract. If the provider has made statements during the sales process about uptime, redundancy, business continuity or failover arrangements, those points may matter. But they are much easier to rely on if they appear clearly in the signed agreement rather than in marketing materials or verbal conversations.

What a realistic uptime promise looks like

An uptime commitment should be specific enough to measure and enforce. A clause that says the provider will use reasonable efforts to maintain availability may sound reassuring, but it can be difficult to turn into a practical remedy.

Most providers instead use a service level target, such as 99.5 per cent or 99.9 per cent availability per month. That sounds precise, but you still need to read the detail behind it.

For example, the contract should answer:

• Whether the percentage is measured monthly, quarterly or annually
• Whether planned maintenance is excluded
• Whether partial service degradation counts, or only a complete outage
• Whether downtime is measured across the whole platform or only the affected module
• How incidents are logged and who decides if the threshold has been met

A provider may advertise 99.9 per cent uptime, but exclude enough categories of interruption that the promise becomes much narrower in practice.

Downtime is not only about outages

Many disputes are not about a full system shutdown. They are about severe slowness, failed integrations, delayed processing, inability to export data, or a major feature being unavailable. If the clause only covers total service unavailability, your business may have little recourse for a serious but partial failure.

This is where founders often get caught. The platform is technically still online, so the provider says there has been no downtime, even though your team cannot process orders or complete key tasks.

Remedies matter as much as definitions

A downtime clause only helps if it includes a practical remedy. In many SaaS contracts, the sole remedy is a service credit against future fees. That may be acceptable for low-cost software, but not where the software supports core revenue or compliance functions.

Before you accept the provider's standard terms, ask whether the contract should include:

• Service credits for missed service levels
• Refund rights for prolonged outages
• Escalation rights to senior support or account management
• A right to terminate if outages happen repeatedly or exceed a threshold
• Assistance with transition or data export if you leave

For some businesses, the right to exit cleanly is more valuable than a small credit on a future invoice.

Legal Issues To Check Before You Sign

The main legal issues are definition, remedy, liability and evidence. Before you sign, make sure the downtime clause works with the rest of the agreement and reflects the real operational risk to your business.

1. Definition of downtime and service failure

The contract should state what counts as downtime in plain terms. If the wording is vague, a provider may argue that the incident was only degraded performance, a third party issue or planned maintenance.

Look for clear drafting on:

• Total unavailability versus partial feature failure
• Performance degradation, latency or failed processing
• Outages affecting integrations, APIs or mobile access
• Scheduled maintenance windows and notice periods
• Emergency maintenance and whether that is excluded from uptime calculations

If your business depends on a specific function, such as payment processing, stock control or booking confirmation, that should be reflected in the service description or service levels.

2. Service levels and support commitments

A good SaaS agreement separates uptime metrics from support response promises. You need both. A high uptime target does not help much if incidents are acknowledged slowly or left unresolved for days.

Check whether the contract sets out:

• Priority levels for incidents
• Response times for each priority
• Target fix times or workaround times
• Support hours, including whether support is 24/7 or business hours only
• The method for reporting incidents and escalating unresolved problems

If your business trades outside standard office hours, a weekday support model may not be enough.

3. Service credits and financial remedies

Service credits are common, but they are often tightly restricted. The provider may require you to claim the credit within a short period, submit evidence in a specified form or accept the credit as your only remedy.

Read the clause closely for:

• The amount of the credit and whether it is meaningful compared with the likely loss
• Any requirement to notify the provider within a short deadline
• Whether the credit is automatic or only available if you claim it
• Whether credits apply to the affected service only or the full subscription
• Whether the credit is the exclusive remedy for downtime

Exclusive remedy wording can be a major issue. It may prevent you from seeking other contractual remedies, subject to the wider wording of the agreement and applicable law.

4. Termination rights for repeated or serious downtime

If the software is business critical, you should consider whether repeated service failures should trigger a right to terminate. Otherwise, you may be stuck in a contract that does not work, while receiving only modest credits.

Useful triggers might include:

• Failure to meet service levels for a set number of months
• A single prolonged outage above a stated threshold
• Repeated critical incidents within a quarter or year
• A material breach that is not fixed within a cure period

You should also check what happens on exit. Data export, migration assistance, continuing access for a limited handover period and deletion timing can all matter if you need to switch providers quickly.

5. Liability caps and exclusions

The limitation of liability clause often has more impact than the service level wording. A provider may promise credits or performance targets in one section, then cap all liability at a low multiple of fees in another section.

Watch for exclusions relating to:

• Loss of profit, revenue, savings or goodwill
• Indirect or consequential loss
• Data loss or corruption
• Third party hosting or infrastructure failures
• Cyber incidents or denial of service events

Some exclusions are standard in commercial contracts, but the overall position should still make commercial sense. If the software holds key operational or compliance data, a very low cap paired with broad exclusions may leave your business carrying most of the risk.

6. Data access, backup and disaster recovery

Downtime is closely connected to data risk. If the system goes down, can you still access essential data, or at least retrieve it quickly? The agreement should make clear what backup, restoration and disaster recovery commitments exist.

You should check:

• How often data is backed up
• How long backups are retained
• Whether backups are encrypted and segregated
• Recovery time and recovery point objectives, if stated
• What help is available if you need to restore or export data after a major outage

If the provider processes personal data on your behalf, the downtime position may also interact with your own UK GDPR obligations and data protection responsibilities. A serious outage may affect your ability to access, correct or safeguard personal data, or to respond to customer requests in time.

7. Supplier promises made before contract signature

Sales calls and proposals often include assurances about uptime, redundancy and resilience. Before you rely on a verbal promise, ask for the important points to be added to the contract, schedule or order form.

This is especially important where the agreement contains an entire agreement clause. That wording may limit your ability to rely on statements outside the signed contract, although the exact effect depends on the drafting and the circumstances.

8. Industry-specific and operational issues

Some sectors need more than a generic service level schedule. If you operate in ecommerce, fintech, health, education or regulated services, outages can affect customer communications, compliance deadlines and record-keeping obligations.

In those cases, it can be sensible to align the contract with your operational reality, such as:

• Peak trading periods or seasonal demand
• Mandatory retention or audit access requirements
• Customer-facing service commitments you have already made
• Business continuity plans and internal incident response procedures

Common Mistakes With Downtime Clauses in SaaS Agreements

The most common mistake is treating a downtime clause as a technical appendix rather than a commercial risk term. Before you sign, read it as if the software fails on your busiest day, because that is when the wording matters.

Accepting vague uptime language

Founders often assume terms like high availability or commercially reasonable efforts are enough. They usually are not. Those phrases may set a softer standard than a measurable service level and can be harder to enforce.

Ignoring maintenance exclusions

Scheduled maintenance is often excluded from uptime calculations, which is not unusual. The problem comes when maintenance windows are broad, notice periods are short, or emergency maintenance is defined so widely that many interruptions fall outside the uptime commitment.

If your busiest period is evenings or weekends, maintenance timing matters a lot.

Relying on service credits that are too small

A few percentage points of monthly fees may not come close to the harm caused by a major outage. This is a frequent issue for ecommerce businesses, agencies, SaaS resellers and service providers whose own customer commitments depend on the platform staying available.

Missing the claim process

Some contracts require customers to claim service credits within a short period after the incident. If your team is focused on fixing operational fallout, it is easy to miss the deadline and lose the credit altogether.

Overlooking integration failures

Your provider may say the core platform was available, while the actual problem sat in an API, plug-in or third party connector. If those integrations are essential to your workflow, the contract should deal with them explicitly where possible.

Failing to secure a termination right

Many customers focus on credits but forget about exit rights. If the service fails repeatedly, the practical priority is often to move to another provider without being locked into a long term and a difficult data export process.

Assuming all SaaS providers use the same standards

They do not. A mature enterprise supplier may offer detailed service levels, incident management and business continuity commitments. A smaller provider may offer very limited terms. The contract should be assessed against the role the software plays in your business, not against generic market assumptions.

Letting liability clauses undo the rest of the deal

A carefully negotiated uptime schedule can still be undermined by a harsh limitation of liability clause. This is where legal review adds value. You need to read the promises and the carve-outs together, not in isolation.

FAQs

Are downtime clauses legally required in a SaaS agreement?

No, there is no general rule that every SaaS contract must include a detailed downtime clause. But if the software is important to your operations, leaving the issue vague creates avoidable risk and can make disputes harder to resolve.

What uptime percentage should a UK business ask for?

There is no single right percentage. The right target depends on how critical the software is, when you trade, and what losses an outage could cause. A headline percentage matters less than the exclusions, remedies and support commitments behind it.

Can we terminate a SaaS agreement if the software keeps going down?

Only if the contract gives you a clear termination right, or if the circumstances amount to a serious breach under the agreement and general contract law. It is much better to include express exit triggers before you sign rather than argue about them later.

Do service credits stop us from claiming anything else?

Sometimes. Many SaaS contracts say service credits are the sole or exclusive remedy for downtime. Whether that blocks other claims depends on the exact wording and the wider agreement, so this point should be checked carefully.

Should downtime clauses deal with data backup and recovery?

Yes, especially where the platform stores operational or personal data. Availability, backup, restoration and exit support are closely linked, and problems often arise when the contract covers one of these points but not the others.

Key Takeaways

• Downtime clauses in SaaS agreements should define outages clearly, including partial failures, degraded performance and maintenance exclusions.
• Uptime percentages are only one part of the picture, support response times, remedies and evidence requirements matter just as much.
• Service credits may be too limited on their own, especially for business critical software, so termination rights and exit support should be considered.
• Liability caps, exclusions, backup commitments and disaster recovery wording can significantly affect your real level of protection.
• Sales promises about reliability and resilience should be written into the contract before you sign, rather than left in emails or conversations.
• UK businesses should review downtime terms in the context of their own operations, customer commitments and data protection responsibilities.

If you want help with service levels, liability caps, termination rights, data access and exit terms, you can reach us on 08081347754 or team@sprintlaw.co.uk for a free, no-obligations chat.