Review a SaaS service-level agreement before relying on its uptime promise

A supplier offers 99.9% uptime. Your service owner hears that the platform will rarely interrupt work. The agreement may promise something narrower: a particular measure for particular functions, with exclusions and a credit if the threshold is missed.

For a lean third-party risk team, the useful question is whether that measure describes the service the organisation needs. You can answer it with a short review that connects the agreement to an operating scenario.

This is an original educational review method, not legal advice or a conclusion that any contract meets regulatory requirements. The supplier examples illustrate differences in published terms, not an assessment of those suppliers. Check the agreement and version applicable to your purchase.

Build a six-field SLA review

1. Covered service

Record the product, plan, environment and functions included. Then compare that boundary with the workflow your team actually uses.

For example, Atlassian's SLA identifies covered experiences and, subject to specified exceptions, covers browser-based experiences rather than integrations, API calls or mobile versions. An integration your business depends on should not be assumed covered because the product name appears in the agreement.

Ask the technical owner to map each critical workflow step to the relevant commitment. Keep anything outside that boundary visible.

2. Measurement method

Capture the target, measurement period, denominator and definition of downtime. Also identify the time zone, rounding rules and any minimum duration or error threshold.

The Google Workspace SLA uses minutes in a calendar month for its uptime calculation. Its downtime definition refers to the covered user web interface having more than a five per cent user error rate, measured using server-side errors. That is more specific than a user reporting that something did not work.

Ask for one worked calculation using the supplier's reporting method. Do not substitute an annual average for a monthly commitment.

3. Exclusions and dependencies

List the interruptions that do not count and the conditions attached to each exclusion. Check maintenance, customer configuration, networks and third-party components rather than assuming every outage is treated alike.

For example, Atlassian's published exclusions include routine scheduled maintenance and reasonable emergency maintenance under its maintenance policy. This does not establish what another supplier excludes.

Ask who identifies the cause, what evidence supports the classification and how a disputed exclusion is handled. Record an unresolved interpretation as a question for the appropriate technical or legal reviewer.

4. Evidence and reporting

Identify the contractual measurement source and what your organisation can independently observe. Atlassian's SLA states that its monitoring and logging infrastructure determines whether its commitment was met. Your own observations can still help explain user impact, but they do not automatically replace the contractual measure. Source: Atlassian SLA.

Retain incident times, affected functions and relevant ticket references. Use consistent time zones and avoid putting credentials or personal information into broadly shared logs. A supplier status page is useful context; check whether it describes your affected service and time window.

5. Remedy and claim process

Record the credit bands, calculation base, cap, submission deadline and evidence required. Name the person responsible for making a claim and check any reseller route.

As an infrastructure example, the Amazon Compute SLA calculates credits against defined affected EC2 charges. It requires claims by the end of the second billing cycle after the incident and specifies supporting information. A SaaS supplier using AWS does not automatically pass that commitment or claim route through to its customers.

Google’s Site Reliability Engineering book distinguishes a service-level indicator (the measure), an objective (the target) and an agreement with consequences. That distinction helps separate a monitoring dashboard from a contractual commitment.

Keep the possible credit separate from the operational cost of an interruption. Ask legal counsel about contractual remedies and their limits rather than treating a service credit as complete protection.

6. Operational response and owner

Write down what your organisation will do when the service fails, even if no SLA breach has occurred. Identify the service owner, incident contact, escalation route and practical fallback.

Separate a support acknowledgement target from a restoration commitment. Likewise, a monthly availability percentage does not establish the maximum length of one interruption or when queued work will be completed. Test those questions with operations before accepting the SLA as evidence of recoverability.

Work through one fictional month

Harbour Services, a fictional Australian organisation, uses a SaaS platform to allocate shifts. Its invented agreement promises 99.9% monthly availability. For this example only, the denominator is every minute in the month and qualifying scheduled maintenance is excluded from downtime without reducing that denominator.

In a 31-day month there are 44,640 minutes. Harbour experiences:

• 90 minutes of unavailable service during maintenance that meets the hypothetical exclusion.
• 30 minutes of qualifying unplanned downtime.
• No other interruptions.

The contractual calculation is:

(44,640 minus 30) divided by 44,640, multiplied by 100 = approximately 99.933%.

The 99.9% commitment is met under these invented rules. Counting all 120 unavailable minutes instead gives approximately 99.731%. That second figure describes a different measure; it is not the contractual result.

Neither calculation explains the whole business consequence. If the unplanned interruption occurs just before shift allocation, 30 minutes may create a significant backlog. The team should record that impact even though the monthly SLA is met.

Under this simplified formula, 99.9% corresponds to 44.64 qualifying downtime minutes in the month. It is not a promise that every interruption will end within 44.64 minutes. Actual terms may use different definitions, exclusions or rounding.

Finish with a decision someone can use

Keep the completed six fields beside the applicable agreement and a sample calculation. Assign each unresolved question an owner and state what evidence would resolve it. Where the coverage is narrower than the workflow, decide whether to clarify terms, strengthen the fallback or escalate the remaining exposure.

Use the contract-review guide for the wider arrangement and the ongoing-monitoring guide to connect reported performance with operational outcomes.

Start with one important SaaS service. Ask its owner to explain which interruptions count towards the uptime promise and what the business will do about the ones that do not.