Downtime Clauses in SaaS Agreements: Essential New Zealand Insights

Downtime looks like a technical issue, but in a SaaS agreement it is really a risk allocation issue. New Zealand businesses often sign standard software terms that talk about uptime in broad marketing language, stay silent on service credits, or exclude almost all liability when the platform goes offline. That becomes a real problem when your team cannot access core systems, your customers cannot transact, or you miss deadlines because the provider says the outage was scheduled maintenance or outside its control.

Three mistakes come up repeatedly. Businesses rely on a verbal promise about reliability instead of the written contract, accept a vague service level with no practical remedy, or overlook how the downtime clause interacts with termination rights, privacy obligations, and liability caps. Here, we explain what downtime clauses in SaaS agreements usually cover, what New Zealand businesses should check before they sign, and how to avoid common drafting traps when the provider's standard terms look one sided.

Overview

Downtime clauses set the rules for when a software service is unavailable, how availability is measured, what exceptions apply, and what remedy you get if the provider misses the promised standard. For many SMEs, these clauses matter most when the software is business critical, customer facing, or tied to regulated data and operational deadlines.

• The uptime commitment and how it is measured, including the service window and calculation method.
• Excluded events, such as scheduled maintenance, third party failures, force majeure, customer misuse, or internet outages.
• Notice obligations for planned maintenance and incident response expectations for major outages.
• Whether the remedy is meaningful, including service credits, fee reductions, termination rights, or other relief.
• How the downtime clause interacts with liability caps, indemnities, privacy and security promises, and data access rights.
• Evidence and reporting, including logs, outage reports, and who decides whether the SLA has been breached.

What Downtime Clauses in SaaS Agreements Means For New Zealand Businesses

Downtime clauses in SaaS agreements decide who wears the commercial pain when software goes offline. If your operations depend on cloud software, the wording can affect revenue, customer complaints, missed service levels, staff productivity, and even your own contractual obligations to others.

Most SaaS providers offer standard terms on a take it or leave it basis. Those terms often contain an availability promise, usually expressed as a percentage, but the real position sits in the detail around exclusions, remedies, and the provider's ability to change the service.

What a downtime clause usually covers

A well drafted clause will usually deal with:

• the target uptime percentage, such as 99.5 percent or 99.9 percent in a monthly measurement period
• the definition of downtime, including whether partial outages or severe performance degradation count
• scheduled maintenance windows and how much notice must be given
• incident severity levels and response or restoration timeframes
• service credits or other remedies if the uptime target is missed
• events that are carved out and do not count against availability

This is where founders often get caught. A provider might advertise "high availability", but the contract may define downtime so narrowly that long periods of degraded service do not count at all.

Why the issue matters commercially

If your accounting platform, CRM, ecommerce backend, booking system, or workforce software is unavailable, the costs can pile up quickly. You may lose sales, spend staff time on workarounds, miss reporting dates, or breach promises you have made to your own customers.

For a New Zealand business, the impact can be even sharper where the software supports cross border trade, round the clock online sales, or sensitive personal information. A system outage can become a privacy issue if people cannot access or secure data properly, or if emergency workarounds increase security risk.

New Zealand legal context

In New Zealand, SaaS arrangements are mainly governed by contract law, but the wording also sits alongside broader obligations. Marketing statements about reliability and uptime should line up with the contract because misleading representations can create Fair Trading Act risk. If the service handles personal information, the provider's availability and incident management commitments may also matter under the Privacy Act 2020, especially where outages affect access, security, or breach response.

The Contract and Commercial Law Act 2017 is relevant to how contractual rights and remedies operate, but the practical outcome usually turns on the specific drafting. For business to business deals, parties often agree to limit or contract out of certain rights where the law allows it, particularly where both sides are in trade. That makes the written terms even more important.

Some businesses also assume the Consumer Guarantees Act will give them a fallback if software fails. In many B2B SaaS deals, the parties contract out of that regime where they are both in trade and the law permits it. Before you accept the provider's standard terms, check whether that has happened and whether the agreement leaves you with a realistic remedy if the software is unavailable.

When downtime clauses matter most

The clause deserves closer attention if the software is central to your operations. Common examples include:

• point of sale, ecommerce, or online ordering systems
• inventory, logistics, or warehouse management tools
• health, finance, or professional services platforms handling sensitive data
• client portals with promised availability or response times
• software you are reselling, embedding, or relying on to deliver your own service levels

If the platform is non essential and easy to replace, a light touch clause may be enough. If the software is core infrastructure, you usually need more than a headline uptime number.

Legal Issues To Check Before You Sign

The right downtime clause should tell you exactly when a service failure counts, what the provider must do, and what happens if performance falls short. Before you sign a contract, focus on the parts that decide whether the promise is real or mostly cosmetic.

1. How uptime is defined and measured

Start with the service level itself. A target of 99.9 percent sounds strong, but over a month that still allows a meaningful amount of outage time. The clause should explain the measurement period, the business hours or 24/7 basis, and whether downtime includes partial loss of functionality.

Check points such as:

• whether uptime is measured monthly, quarterly, or over a longer period
• whether the commitment applies at all times or only during a defined service window
• whether severe slowdowns, login failures, or API failures count as downtime
• whether there are separate standards for critical features

If your team only uses the system during New Zealand business hours, a provider may offer lower support outside those hours. If you run online sales continuously, you may need availability measured on a full time basis.

2. Exclusions and carve outs

The exclusions are often more important than the uptime target. Many providers remove liability for scheduled maintenance, emergency maintenance, internet issues, cloud infrastructure failures, third party software problems, customer configuration errors, cyber attacks, and force majeure events.

Some exclusions are fair. Others are drafted so broadly that most real world outages never count. Before you rely on a verbal promise, review whether the carve outs cover:

• upstream hosting provider failures
• integrations and APIs the SaaS depends on
• security incidents and denial of service attacks
• beta or newly released features
• acts or omissions by your staff, contractors, or users

If the provider relies heavily on subcontractors or external cloud infrastructure, ask who remains responsible for the overall service. Otherwise, you may hear that the outage was someone else's fault and therefore outside the SLA.

3. Scheduled maintenance and notice periods

Most SaaS platforms need maintenance. The issue is not whether maintenance is allowed, but how it is controlled. The contract should say when maintenance can occur, how much notice must be given, and whether emergency maintenance is limited to genuine urgent situations.

For businesses with peak trading periods, maintenance windows matter a lot. A retail platform that goes down overnight in another country may still be offline during your busiest New Zealand sales period.

4. Remedies for downtime

A downtime clause is only as useful as the remedy attached to it. Service credits are common, but they may be small compared with your actual loss.

Look closely at whether the agreement provides:

• automatic service credits or a requirement for you to claim them within a short timeframe
• fee reductions for repeated failure
• a right to terminate after persistent or major outages
• refunds for prepaid fees if the service fails badly
• priority escalation and support obligations during incidents

The main risk is a clause that says service credits are your sole and exclusive remedy, especially where those credits are minimal. If the software is mission critical, you may need an express termination right if uptime repeatedly falls below the agreed level.

5. Liability caps and exclusions of loss

Many providers pair the downtime clause with a low liability cap, often limited to fees paid in a short period, and broad exclusions for indirect or consequential loss. That can leave you with little recovery even if the outage causes real business damage.

Caps and exclusions are standard in SaaS contracts, but they should be commercially sensible. If the provider wants a strict cap, think about whether some categories should sit outside it, such as confidentiality breaches, privacy failures, wilful misconduct, or failure to return your data on exit. The right approach depends on the deal size, bargaining power, and the software's importance to your operations.

6. Termination and exit rights

If the service keeps failing, you need a practical way out. A contract should say whether repeated downtime is a material breach, whether there is a cure period, and how you can extract your data and move to another provider.

Check whether the agreement covers:

• termination for chronic SLA failure over a set number of months
• data export formats and timing
• transition support at the end of the contract
• continued access to records for a short period after termination

This becomes especially important where the platform stores customer histories, transaction records, or regulated information you cannot afford to lose.

7. Privacy, security, and incident handling

Outages and security incidents often overlap. A cyber event may trigger downtime, and a rushed workaround may increase privacy risk. If the provider processes personal information, the agreement should work consistently with your privacy obligations and incident response process.

Points worth checking include:

• how quickly the provider must notify you of a security incident or major outage
• who is responsible for customer communications if the outage affects data access
• whether backups, disaster recovery, and restoration testing are described clearly
• whether the provider can suspend the service for security reasons and on what terms

Where the software supports your own customer commitments, ask whether you can obtain outage reports and root cause information. Without that, it is hard to explain the issue to clients or enforce your own downstream contracts.

8. Change control and unilateral updates

Some standard SaaS terms allow the provider to change the SLA or service description on notice, or even by posting updated terms. That can quietly reduce your protection after signing.

Before you accept the provider's standard terms, check whether the service levels, support model, or maintenance rules can be changed unilaterally. For higher value arrangements, you may want changes to key commercial terms documented in writing and agreed by both parties.

Common Mistakes With Downtime Clauses in SaaS Agreements

Most disputes about software downtime start with assumptions that never made it into the contract. New Zealand businesses can avoid a lot of pain by tightening a few recurring weak spots before they sign.

Treating marketing claims as contractual promises

Sales material may talk about reliability, enterprise grade hosting, or near constant availability. Unless those commitments are reflected in the agreement, they may be difficult to enforce.

Make sure any promise you are relying on appears in the signed contract or incorporated SLA. That includes uptime percentages, support hours, response times, and maintenance notice periods.

Ignoring the claim process for service credits

Some agreements say you must request service credits within a very short time after the outage, sometimes with detailed evidence. If you miss the deadline, the credit is lost.

This can become a trap for small teams focused on restoring operations rather than managing contract administration. If service credits matter to you, negotiate an automatic credit process or a more realistic claim window.

Accepting a narrow definition of downtime

A platform can be technically online but practically unusable. Slow processing, broken integrations, failed payments, and intermittent access can all disrupt a business without fitting a narrow outage definition.

If certain features are essential, the clause should reflect that. You may need wording that captures material degradation of service, not only total unavailability.

Overlooking your own customer commitments

If you promise your clients certain service levels, your provider's downtime terms need to support those promises. Otherwise, you carry the risk gap between what you have promised and what your supplier will actually stand behind.

This is common in managed services, ecommerce, agencies, and software businesses that resell or rely on third party tools. Before you sign, compare your upstream and downstream obligations side by side.

Missing the interaction with liability limits

An apparently decent SLA can be undermined by a strict sole remedy clause and a very low liability cap. Founders often review the uptime percentage but not the remedies section or exclusion clauses that sit elsewhere in the contract.

Read the whole risk allocation package together. The uptime clause, service credit clause, indemnities, exclusions, and limitation of liability should make commercial sense as a set.

Failing to secure exit rights

When software fails repeatedly, the practical question is how quickly you can switch. Businesses often spend weeks trying to retrieve data or negotiate migration help after the relationship has already broken down.

Put the exit mechanics in writing at the outset. Data portability, retention periods, and transition support are much easier to secure before the contract is signed than after a serious outage.

Relying on informal workarounds

During negotiations, a provider may say it will "look after you" if there is a major incident. That may be true commercially, but it is not a substitute for a written contractual right.

Where a concession matters, ask for it in the agreement. This is particularly true for major incident response, named contacts, escalation paths, and termination rights after repeated downtime.

FAQs

Is a service credit enough if the software goes down?

Not always. Service credits can be useful for minor outages, but they are often far smaller than the actual loss suffered by a business. If the software is critical, consider whether you also need termination rights, fee adjustments, or stronger support obligations.

Can a provider exclude downtime caused by its cloud host or other suppliers?

It often tries to, but that does not mean you have to accept it. If the provider chooses the infrastructure and controls the service delivery model, many customers will expect it to remain responsible for the end to end service, even if subcontractors are involved.

Should scheduled maintenance count as downtime?

Usually not, if it is genuinely planned, limited, and notified properly. The real issue is whether the maintenance window and notice period work for your business, and whether emergency maintenance is defined narrowly enough to prevent overuse.

What uptime percentage should a New Zealand SME ask for?

There is no single right number. The answer depends on how critical the software is, when you use it, and what harm an outage would cause. A higher uptime target matters, but the exclusions, remedies, and support commitments are just as important.

Do standard SaaS terms usually allow termination for repeated downtime?

Not always. Many standard terms provide only service credits. If repeated outages would seriously disrupt your business, ask for a clear right to terminate after defined SLA failures across a set period.

Key Takeaways

• Downtime clauses in SaaS agreements are about risk allocation, not just technical performance.
• The key issues are the uptime metric, how downtime is defined, exclusions, maintenance rules, remedies, and evidence of breach.
• New Zealand businesses should also check how the clause interacts with the Fair Trading Act, Privacy Act 2020, contractual liability caps, and any ability to contract out of statutory protections in a B2B deal.
• Service credits alone may not protect a business that relies heavily on the software, especially if the contract makes them the exclusive remedy.
• Repeated or serious outages should trigger practical rights, including escalation, termination, data export, and transition support.
• The safest approach is to review the SLA, remedies, liability provisions, and exit terms together before you sign or rely on a provider's standard terms.

If you want help with contract review, SLA drafting, liability caps, termination rights, and privacy obligations, you can reach us on 0800 002 184 or team@sprintlaw.co.nz for a free, no-obligations chat.