How to Review a Service Level Agreement (2026 Checklist)

A service level agreement (SLA) is the part of a services or SaaS contract that promises how well the service will perform and what happens if it does not. Reviewing an SLA well means reading past the headline number. A "99.9% uptime" promise is only as strong as the way uptime is defined, what is excluded from the calculation, how it is measured, and what you actually get when the target is missed. A weak SLA can pair an impressive percentage with exclusions that make it nearly meaningless. This is general guidance, not legal advice. ## The fast answer: what to check first Check four things in order. First, how is the service level defined and measured (and by whom). Second, what is excluded from the calculation. Third, what is the remedy when a target is missed, and is it the only remedy. Fourth, is there an exit right for repeated or severe failures. The percentage matters far less than these four. ## Clause-by-clause review checklist ### The service levels themselves Identify every committed level, not just uptime: availability, support response and resolution times, performance or latency, and any recovery-time and recovery-point objectives for backups. Each should be a number, not an adjective. "High availability" is not a service level; "99.9% per calendar month" is. ### How availability is defined Read the definition of "available" and "downtime". A fair SLA counts the service as down when core functions do not work for users. A weak one only counts a total outage, so a service that is slow or partly broken still counts as "up". Check the measurement window too: a monthly 99.9% allows more downtime than the same figure measured annually in a single burst. ### Measurement and reporting Who measures, with what tools, and do you get to see the data? The strongest SLAs are measured by an independent monitor or give you access to the raw figures. The weakest rely only on the provider's own logs with no reporting. Check whether you must claim a credit within a short window and in a set format, since missing that can forfeit the remedy. ### Exclusions This is where most of the real risk hides. Common exclusions are scheduled maintenance, emergency maintenance, your own misuse, third-party networks, and force majeure. Each can be reasonable, but read the edges: is maintenance capped and notified in advance, or open-ended? Are "beta" features excluded? Is anything "outside the provider's direct control" excluded so broadly that it swallows the promise? ### Support and severity levels Check the support model: severity definitions, target response times for each severity, resolution or workaround targets, hours of coverage (business hours or 24x7), and escalation paths. Confirm the response time is a real commitment, not a target the provider only tries to meet. ### Remedies and service credits Understand what you get when a level is missed. Usually it is service credits (a percentage of fees back), tiered by how badly the target was missed, and capped at a monthly maximum. Two questions matter: is the credit worth enough to change behaviour, and is it the sole and exclusive remedy? If credits are the only remedy, a provider can underperform and simply discount, so negotiate a termination right for chronic breaches. ### Chronic failure and termination Look for a clause that lets you terminate without penalty if the service misses targets repeatedly (for example, three months in a rolling period) or suffers a single severe outage beyond a set length. This is often the most valuable protection in the whole SLA. ### Maintenance windows Check how much notice you get for planned maintenance, whether it is capped per month, whether it counts against uptime, and whether emergency maintenance has any limit at all. ### Data, backups and continuity If the service holds your data, check backup frequency, recovery objectives, and what happens to your data during and after an outage or on exit. ## Red flags to push back on A high uptime number with "availability" defined only as total outage. Exclusions broad enough to cover most real failures. Measurement by the provider alone with no reporting. Service credits as the sole remedy, capped low. No termination right for repeated failures. Short, strict credit-claim windows designed to make remedies hard to collect. ## How the law changes by jurisdiction Contract law is national, so the same words do not behave the same everywhere. In common-law systems (India, the UK, Singapore, Australia, the US) courts lean on the written terms and read ambiguity against the drafter. Governing-law and jurisdiction clauses decide which country's rules apply and where disputes are heard; check they match where the parties and the assets actually are. In India, stamp duty and, for many instruments, registration are live concerns, and the Indian Contract Act 1872 governs formation. In the US, state law varies and the Uniform Commercial Code may apply where goods are involved. Across the EU and UK, data and consumer rules add mandatory terms you cannot contract out of. When in doubt, take local advice; this page is general information, not legal advice. ## A simple review workflow Translate each service level into "what does this allow to go wrong, and what do I get if it does". Work the uptime definition and exclusions together, since they only make sense as a pair. Confirm the remedy is meaningful and not the only one. Keep an issues list with the clause reference, the real-world risk and your proposed change, and get the operations or engineering owner to sanity-check the numbers against what the business actually needs. ## One workspace for drafting, review and tracking Everything above is work you can do by hand: read the draft, mark the risky positions, line up your redlines, remember the dates. The friction is rarely the reading. It is that the draft, the comments, the versions, the signed copy and the renewal date usually live in five different places. The simple idea behind an AI contract workspace is to keep that work together: draft from your own catalogue, see each clause flagged favourable, neutral or unfavourable to you, edit clauses in plain English and get a clean diff, keep a live activity timeline so every version is traceable, and track key dates and obligations so renewals and notices do not slip. Adira is one such workspace, built on Anthropic's Claude and tuned to how your company contracts. It is India-first today; deeper support for other jurisdictions and a single legal health pane (the Company Command Centre) are on the roadmap. None of that replaces legal advice on a specific deal. It just means the review you ran once does not have to be rebuilt from scratch next quarter.