SaaS Uptime Clauses for UK Startups

A SaaS uptime clause can help close bigger customers, but the wrong wording can turn a technical target into an open-ended legal promise. Founders often copy a 99.9% uptime guarantee clause, forget to define how availability is measured, or offer service credits without saying they are the customer's only remedy.

The real decision is not simply whether your platform is reliable. It is what level of availability you can evidence, what downtime should be excluded, how planned maintenance will work, and what happens when you miss the target.

A well drafted SaaS service level agreement in the UK should support sales without exposing the business to disproportionate refunds, termination rights or uncapped liability. The aim is to offer confidence, not guarantee perfection.

What an Uptime Clause Should Decide

A SaaS uptime clause should define the availability promise, the measurement method, the exclusions, the remedy and the limit of that remedy.

In practical terms, the clause sits between your sales promise and your operational reality. It tells customers how reliable the service is expected to be and gives them a process if the service falls short. For a founder negotiating with a procurement team, it can also stop the conversation drifting into vague assurances like "we are always online" or "we will compensate you for any outage".

The clause can appear in your main SaaS terms and conditions, in an order form, or in a separate service level agreement. Some businesses use a short software availability clause for self-serve customers and a more detailed SLA for enterprise customers. The format matters less than having clear terms that fit together.

A useful uptime clause usually answers these questions:

• What service is covered? The customer-facing application, API, admin dashboard, support portal or another defined part of the software.
• What uptime target applies? For example, 99.5% or 99.9% availability during a monthly service period.
• When is the service treated as unavailable? The clause should define outage conditions rather than leaving availability to argument.
• What periods are excluded? Planned maintenance, customer misuse, third-party failures and force majeure events are common exclusions.
• How does the customer claim a remedy? There should be a time limit, evidence requirement and process for assessing the claim.
• What remedy is available? SaaS service credits, an extension of subscription time, or in some cases a termination right for repeated failures.
• How does it interact with liability caps? The clause should not accidentally override your limitation of liability wording.

The legal risk comes from uncertainty. If your contract says the platform will be available "at all times" or that you will be liable for "all losses caused by downtime", a customer may argue that the promise is far broader than you intended. That can be especially difficult if the customer uses your tool for revenue-generating activity, payroll, healthcare scheduling, logistics, payment workflows or other business-critical functions.

For UK B2B contracts, parties generally have freedom to agree commercial service levels, but unfair or unreasonable limitations can be challenged in some situations, particularly under the Unfair Contract Terms Act 1977 when one party deals on the other's written standard terms. If you sell to consumers as well as businesses, the Consumer Rights Act 2015 can also be relevant. Most B2B SaaS startups should assume their clauses need to be clear, balanced and commercially defensible.

Choosing an Uptime Target You Can Actually Support

Your uptime percentage should reflect your architecture, hosting arrangements, monitoring capability and support resources, not just what competitors put in their enterprise deck.

The difference between 99%, 99.5%, 99.9% and 99.99% can be significant. A target that looks like a small decimal point change can materially reduce the downtime you are permitted to have in a month. If you choose an enterprise-grade commitment before your product, DevOps and incident response processes are ready, you may create a recurring credit obligation that eats into revenue and damages trust.

Founders usually face this decision at one of three moments. A first large customer asks for an SLA as part of procurement. A reseller or channel partner wants customer contract commitments it can pass on to its own customers. Or the business moves from monthly self-serve subscriptions to annual contracts and needs more formal service terms.

When deciding what to promise, consider:

• Your current uptime data: If you have six to twelve months of monitoring data, use it. If you do not, be cautious about committing to a number you have not tested.
• Your hosting dependencies: Cloud providers, data centres, content delivery networks, payment processors, authentication tools and messaging providers can all affect availability.
• Your customer segment: A hobby tool, marketing dashboard and clinical workflow platform may need very different service levels.
• Your subscription price: Higher commitments usually require higher operational costs. The SLA should be commercially priced into the deal.
• Your internal response process: If you do not have alerting, escalation and incident ownership, a strict SLA can become a liability rather than a trust signal.
• Your support hours: If you only provide support during UK business hours, think carefully before promising 24/7 operational response times.

A founder might be tempted to offer 99.9% availability to win a financial services client. That may be sensible if the product has mature infrastructure, multi-region resilience and a well tested incident process. It may be risky if the same platform is still being deployed manually by a small engineering team on Friday afternoons.

Many startups use tiered service levels. For example, standard plans may receive a general commitment to use reasonable efforts to maintain availability, while enterprise plans receive a defined uptime target and service credits. This can be a sensible commercial approach because it reserves the stronger promise for customers who pay for it and whose contracts justify the extra operational burden.

Be careful with sales wording outside the contract. Website statements, proposals and security questionnaires can become part of the factual background to a dispute. If your marketing page says "guaranteed 100% uptime" but your contract says service credits are limited, you create avoidable tension. Keep your public claims aligned with your customer contract terms and your actual performance.

Planned Maintenance, Exclusions and Measurement Rules

Availability wording only works if the contract explains what counts, what does not count, and who decides the calculation.

A software availability clause should not treat every interruption as a service failure. SaaS platforms need maintenance, updates, security patches, infrastructure changes and sometimes emergency intervention. The contract should recognise this without giving the supplier a blank cheque to take the service offline whenever convenient.

Planned maintenance is usually excluded from uptime calculations if it is notified in advance and scheduled in a way that minimises customer impact. For a UK SaaS business with global users, "outside business hours" may not be enough. You may need to specify a maintenance window by time zone or state that windows will be published through the service status page, admin console or email notice.

A clear maintenance clause may cover:

• Notice: How much advance notice customers should receive for scheduled maintenance.
• Timing: Whether maintenance will usually occur during low-usage periods or specified maintenance windows.
• Emergency changes: Whether you can carry out urgent work without advance notice to address security, stability or compliance issues.
• Duration: Whether planned maintenance is excluded only if it falls within a reasonable duration or published window.
• Customer communications: Where updates will be posted during an outage or maintenance period.

Exclusions are just as important. Common exclusions for a SaaS service level agreement in the UK include downtime caused by the customer's systems, internet connectivity outside your control, the customer's breach of the service agreement, unauthorised modifications, misuse, beta features, third-party integrations, force majeure events and suspension for non-payment or security risks.

Third-party services need careful treatment. If your product depends on a cloud provider, email delivery service, open banking API, payment gateway or AI model provider, you may not control every outage. Your contract can exclude failures caused by third-party services that are outside your reasonable control. However, customers may resist a wide exclusion if the third party is fundamental to the product you are selling. A balanced approach is to exclude external failures where they are not caused by your breach and where you take reasonable steps to restore service.

Measurement rules also matter. Availability can be calculated by calendar month, billing month or service month. It can apply to the whole platform or only to core production services. It can measure complete unavailability or material failure of core functionality. The more precise the definition, the fewer arguments you will have later.

Consider these drafting choices:

• Measurement period: Monthly measurement is common because it aligns with recurring service credits. Annual measurement can smooth out a bad incident, but customers may see it as less meaningful.
• Monitoring source: State whether availability is determined by your monitoring tools, a third-party monitoring service, or mutually agreed data.
• Threshold for downtime: Very short interruptions may be excluded if they do not materially affect access.
• Partial outages: Decide whether a degraded feature counts if customers can still access the main platform.
• API and integrations: If API availability is business-critical, define it separately from the user interface.

For example, a CRM platform might define unavailability as the inability of authorised users to access the core production application, excluding scheduled maintenance and issues caused by the customer's network or third-party integrations. That is much clearer than simply saying the software will be "available 99.9% of the time".

Data protection should also sit beside your uptime thinking. If an outage involves a security incident, personal data breach or loss of access to personal data, UK GDPR and the Data Protection Act 2018 obligations may be triggered. Your data processing terms and incident notification processes should align with the operational commitments in your SLA. An uptime clause should not promise breach notification timings or security outcomes that conflict with your privacy and data protection documents.

Service Credits, Remedies and Liability Boundaries

Service credits should be a controlled commercial remedy for missed uptime targets, not an uncapped refund mechanism or a gateway to wider damages.

SLA credits for SaaS contracts are usually calculated as a percentage of the affected customer's monthly subscription fees. They are often tiered. For example, a small credit may apply if availability falls below the target, and a larger credit may apply if availability falls further. The details depend on the product, pricing model and customer risk profile.

Service credits can be helpful because they give customers a pre-agreed remedy without requiring a dispute about loss. They also give the supplier predictability. The customer knows what they will receive if the SLA is missed, and the SaaS business can model the financial exposure.

A credit clause should usually deal with:

• The credit base: Whether credits apply to monthly fees, annual fees pro-rated for the month, fees for the affected module, or another amount.
• The credit percentage: The credit that applies at each availability level.
• A cap: The maximum credit available for any month or service period.
• Claim process: How quickly the customer must notify you and what information they must provide.
• No cash refund: Whether credits are applied against future invoices rather than paid out in cash.
• Account status: Whether the customer must be up to date with payments to claim credits.
• Exclusive remedy wording: Whether service credits are the sole and exclusive remedy for failure to meet the uptime target.

The exclusive remedy point is critical. Without it, a customer may claim service credits and also argue for damages, termination or broader compensation. That may not be what you priced into the contract. A common approach is to say that service credits are the customer's sole and exclusive remedy for failure to meet the uptime service level, while preserving rights that cannot legally be excluded and any specific termination right you have agreed.

Termination rights need careful calibration. A one-off outage should not usually allow a customer to walk away from a 12-month contract unless the product is mission-critical and the failure is severe. However, an enterprise customer may reasonably ask for a termination right if uptime failures continue over several months. The contract can set a threshold, such as repeated failures in a defined number of service periods, rather than making termination available for any missed target.

Liability boundaries are where many SaaS uptime clauses go wrong. Your limitation of liability clause may include an overall cap, exclusions for indirect or consequential loss, and carve-outs for areas such as fraud, death or personal injury caused by negligence, and other liability that cannot be excluded under English law. Your uptime clause should not undermine that structure.

For example, avoid wording that says you will "indemnify the customer for all losses arising from downtime" unless you have made a deliberate, priced decision to accept that risk. An indemnity can be much broader than a service credit and may be difficult to insure. If the commercial deal requires a stronger remedy, make sure it is capped, linked to fees and aligned with the risk you are actually taking on.

UK contract law allows businesses to limit many types of liability, but limitations need to be drafted carefully. In B2B standard terms, the Unfair Contract Terms Act 1977 can apply to certain exclusions and limitations, including clauses that seek to exclude or restrict liability for negligence or breach. The practical point for founders is simple: liability wording should be reasonable, visible and consistent with the value of the contract.

Service credits should also connect to your invoicing process. If credits are applied to future invoices, what happens if the customer is at the end of the subscription term? If the customer has prepaid annually, will the credit reduce the next renewal invoice? If the customer does not renew, is the credit lost? These details can feel minor during negotiation but become contentious after an outage.

Procurement teams may push for "root cause analysis", incident reports or remediation plans. These can be reasonable for larger customers, but be precise. Promise to provide a reasonable incident summary or post-incident review within a practical timeframe, not a highly detailed forensic report that may contain sensitive security information, third-party confidential information or legally privileged material.

Finally, keep support response times separate from uptime unless you intend them to be linked. A support SLA might measure response or resolution targets for tickets. An uptime SLA measures service availability. If both sit in the same schedule, label them clearly and provide separate remedies, or state that support targets are targets only and do not attract service credits unless expressly stated.

FAQs

Do UK SaaS Startups Have to Offer an Uptime Guarantee?

No. There is no general rule that a UK SaaS startup must offer an uptime guarantee. Many early-stage businesses start with a reasonable efforts availability commitment and only introduce formal service levels for higher value or enterprise customers.

Is 99.9% Availability the Standard for SaaS Contracts?

It is common, but it is not automatically suitable. The right target depends on your product, infrastructure, customer use case, price point and ability to monitor and restore service. Copying a 99.9% commitment without exclusions and measurement rules can create avoidable risk.

Should Service Credits Be the Customer's Only Remedy?

Often, yes. If you are offering credits for missed uptime, the contract should usually state that those credits are the sole and exclusive remedy for that specific service level failure. Any termination rights or non-excludable rights should be dealt with separately.

Can Planned Maintenance Be Excluded From Uptime Calculations?

Yes, planned maintenance is commonly excluded if it is notified properly and kept within the agreed maintenance process. Emergency maintenance can also be excluded, but the wording should be reasonable and should require you to act to protect security, stability or compliance.

What If a Third-Party Cloud Provider Causes the Outage?

Your SLA can exclude downtime caused by third-party services outside your reasonable control. Customers may still expect you to manage the incident, communicate clearly and take reasonable steps to restore access, especially where that provider is central to your service.

Key Takeaways

• A SaaS uptime clause should define the availability target, measurement method, exclusions, claim process, remedy and liability boundaries.
• Do not offer an uptime percentage unless your infrastructure, monitoring data and support processes can support it in practice.
• Planned maintenance, emergency maintenance, customer-side issues and third-party failures should be addressed clearly so availability is measured fairly.
• SLA credits can be useful, but they should be capped, linked to fees and usually framed as the exclusive remedy for missed uptime targets.
• Your uptime clause should align with your limitation of liability, data protection terms, support commitments and customer-facing sales materials.

If you are drafting or negotiating SaaS terms, Sprintlaw UK's online legal team can help with your uptime wording, service credit structure, limitation of liability clause and data protection terms. Call 08081347754 or email team@sprintlaw.co.uk for a free, no-obligations chat.