What an SLA should cover

What an SLA should cover: a practical operator’s checklist

An SLA should turn service expectations into clear commitments between a customer and a service provider. It should remove guesswork about what the provider delivers, when it operates and how both parties handle problems.

A strong SLA covers the service scope, operating boundaries, measurable targets, reporting rules, responsibilities, breach procedures and available remedies. It should also define how the parties calculate performance, record exceptions and review the agreement.

Clear terms create accountability on both sides. The right checks help each team spot weak wording, confirm practical ownership and keep the agreement ready for operational use.

Key takeaways

• The SLA defines services, responsibilities and operating limits.
• Measurable targets show whether the provider meets expectations.
• Breach rules and remedies support accountability when performance falls short.

Service scope, parties and operating boundaries

A useful SLA document names the service, the parties, measurable service tiers and the conditions that govern delivery. It also fixes ownership, contact routes, operating hours, maintenance arrangements, dependencies, exclusions and customer duties so stakeholders can act without relying on assumptions.

Define the covered service and service tiers

The service agreement should identify the service precisely. It should state the products, environments, locations, interfaces and support activities covered by the service-level agreement (SLA). A customer-based SLA may cover one customer across several services, while a service-based SLA may apply the same terms to multiple customers.

The document should define each service tier in operational terms. For example, it might distinguish standard, priority and critical incidents by business impact, then assign a response target, restoration target, support hours and escalation route to each tier. It should explain how the provider classifies incidents and how the customer can challenge an incorrect classification.

The SLA should separate service availability from support response and resolution. It should also state the measurement method, reporting period, calculation exclusions and remedy for missed targets. Named deliverables, performance metrics and acceptance criteria should remove doubt about what service delivery includes.

Set roles, responsibilities and points of contact

The SLA should name the provider, customer and any relevant affiliates or subcontractors. It should identify each party’s roles and responsibilities, including account management, incident handling, change approval, security, billing, data protection and compliance. A responsibility matrix can show who performs, approves, advises and receives updates for each activity.

Each party should provide at least one operational point of contact and one escalation contact. The record should include role titles, monitored email addresses, telephone numbers, coverage arrangements and the process for updating details. Personal information should follow the agreed data protection requirements.

The document should define who can raise incidents, approve changes, request access, accept service reports and authorise emergency action. If the service handles confidential information, the SLA should link to the applicable NDA and data protection terms rather than leaving confidentiality duties unclear.

Specify business hours, communication channels and maintenance windows

The SLA should state the business hours that apply to each service tier and location. It should distinguish business hours from 24-hour monitoring, on-call support and public holidays. If the provider operates across time zones, the document should name the controlling time zone and define how daylight saving changes affect targets.

Communication channels should match the event. A ticket portal may handle routine requests, email may carry formal notices and a telephone route may support critical incidents. The SLA should state which channel starts the response clock, what information the customer must provide and how the provider records status updates.

Scheduled maintenance should use an agreed maintenance schedule. The SLA should specify notice periods, approved maintenance windows, emergency maintenance rules and the effect on availability calculations. It should also require advance notice of expected impact, a completion update and a route for the customer to raise a material objection.

Record dependencies, exclusions and customer obligations

The SLA should list dependencies that affect service delivery, such as telecommunications providers, identity systems, cloud platforms, customer networks, power supplies and third-party data. It should state which party manages each dependency and how a failure affects targets, reporting and escalation.

Exclusions should be specific. They may include unauthorised changes, unsupported configurations, misuse, failures outside the provider’s controlled environment, planned maintenance and force majeure events. The provider should not use broad exclusions to remove obligations it can reasonably control.

Customer obligations should cover access, accurate information, approved configurations, security controls, user administration, timely decisions and cooperation during incidents. The SLA should state what happens when the customer misses an obligation, including whether measurement pauses, costs arise or service limitations apply. Three practical actions help: confirm the dependency register, test every contact route and approve the next maintenance window.

Measurable targets and how performance is calculated

A useful SLA turns service standards into measurable service level objectives (SLOs), defined indicators and clear calculations. It states what counts as success, which data proves it and what happens when service performance falls below the agreed service level.

Choose service level objectives and indicators

The provider should define each service level objective in operational terms. For example, an SLO might require a customer-facing application to achieve a specified monthly uptime, keep request latency below an agreed threshold or maintain error rates within a defined limit.

Each SLO needs a matching service level indicator (SLI). The SLI identifies the measurement method, data set and calculation window. Relevant SLA metrics may include:

• Availability: successful service time divided by scheduled service time
• First response time: elapsed time until a support agent acknowledges a request
• Resolution time: elapsed time until the provider restores service or completes the agreed fix
• Error rate: failed requests divided by total requests
• Request latency: time taken to return a valid response

The SLA should identify exclusions, such as approved maintenance, customer-caused delays and failures in third-party services. It should also state whether the provider calculates compliance using averages, percentiles, thresholds or a combination.

Set availability, uptime and downtime rules

The agreement should define service availability precisely. A monthly uptime target has little value unless the SLA states the scheduled service window, measurement points and minimum outage duration that counts as downtime.

A practical calculation is:

Availability = (scheduled minutes - qualifying downtime) ÷ scheduled minutes × 100

The SLA should explain how monitoring detects an outage, when the clock starts and when it stops. It should also define whether a partial outage, degraded performance or failed regional service counts as downtime. If the provider measures availability from several locations, the agreement should state whether one failed location or a majority of locations triggers an incident.

Approved maintenance requires its own rules. The SLA should specify notice periods, permitted maintenance windows and whether emergency maintenance receives different treatment. It should also state how the provider records incidents and handles overlapping outages so the same downtime is not counted twice.

Define response and resolution targets by severity

Response times and resolution time should vary by severity level. A critical incident affecting most users needs a different target from a routine information request. The SLA should define severity using business impact, affected users, service function and available workaround rather than leaving classification to individual judgement.

The SLA should state whether the clock runs continuously or only during support hours. It should also define when the clock pauses, such as when the provider awaits customer information, and whether restoration and permanent correction have separate targets.

Establish monitoring, reporting and review cadence

Monitoring should collect the data needed to calculate every agreed SLI and KPI. It should cover availability and uptime, downtime, response time, resolution time, request latency and error rates where those measures reflect service quality. The provider should retain timestamps, incident records and maintenance records long enough to support an audit or dispute.

The SLA should set a reporting cadence, such as a monthly service report. Each report should show the target, actual result, calculation method, exclusions, breached SLOs and corrective actions. It should distinguish an average result from a percentile result because averages can hide short periods of poor performance.

The parties should review SLA compliance at a defined interval and after material incidents. They should check whether the metrics still match business needs, whether severity assignments remain consistent and whether recurring breaches require revised capacity, process changes or service credits.

Breach handling, remedies and Monday-ready controls

A workable SLA defines what counts as a breach, who takes control, when each SLA timer starts and what remedy follows. It also connects service desk records, outage recovery, billing adjustments and disaster recovery plans so that customer support can act without debate.

Build escalation procedures and SLA timers

The SLA should define severity levels using operational impact. A P1 might cover a complete service outage, an active security incident or a condition that prevents multiple users from working. A lower priority might cover degraded performance or a single-user fault.

For each level, specify:

• Acknowledgement time: when the service desk confirms receipt
• Response time: when a named technician begins investigation
• Update interval: how often the customer receives a status update
• Workaround target: when temporary service must be restored
• Resolution or recovery target: when normal service should return
• Escalation owner: who takes control if the timer is at risk

The clock should start when the help desk receives a complete ticket through an approved channel, not when staff notice it later. The SLA should state whether waiting for customer information, planned maintenance or an approved third party pauses the timer. A four-level severity structure with defined response and resolution targets can provide a useful starting point, but each target must match the service desk’s actual capacity.

Set service credits, refunds and liability limits

Remedies should be automatic where the provider’s records confirm an SLA breach. The contract can apply service credits against the next billing period, issue a partial refund for an unavailable service or require a corrective action plan for repeated failures. It should state the calculation method, maximum monthly credit and claim deadline.

Credits do not replace every remedy. A serious or repeated breach may trigger additional compensation, a termination clause or contractual indemnification where the provider caused a defined loss. An indemnification clause should identify covered claims, exclusions, control of legal defence and any required customer cooperation.

The liability section should distinguish ordinary service failure from data loss, confidentiality breaches, security incidents and wilful misconduct. It should also define whether service credits count towards the liability cap. The customer should not accept vague penalties that appear strong but lack a calculation, trigger or payment process.

Plan outage recovery and disaster response

The SLA should separate service restoration from permanent correction. During a service outage, the provider should open an incident record, assign an incident lead, publish updates at the agreed interval and record the time of detection, acknowledgement, workaround, recovery and closure. These timestamps support mean time to recovery calculations and later SLA management.

Disaster recovery terms should identify recovery time objectives, recovery point objectives, backup frequency, restoration priorities and communication responsibilities. They should also state which dependencies sit outside the provider’s control, such as customer networks, power, telecoms or subcontracted platforms.

The contract should require a post-incident review for defined P1 events. That review should record the root cause, customer impact, failed controls, corrective actions, owners and due dates. IT service management records should link the incident to any problem, change or risk register entry. A breach management process that includes root cause analysis and service improvement plans supports that discipline.

Run three practical moves this week and a Monday checklist

Three moves can expose weak SLA policies quickly:

1. Test one P1 ticket: Start the timer, escalate it, record each hand-off and check whether the customer receives updates on time.
2. Reconcile one billing period: Compare outage records with availability calculations, service credits and any approved exclusions.
3. Run a recovery check: Restore a selected backup in a controlled test and record the actual recovery time against the SLA target.

On Monday, the operator should confirm that every critical service has a named escalation owner, a current contact list and an approved incident channel. The service desk should verify timer rules, pause conditions and after-hours coverage.

The operator should also check that remedy calculations work in the billing system, termination triggers appear in the contract register and disaster recovery evidence has a review date. Customer support should receive a short script covering breach acknowledgement, next update time and the person accountable for the incident.

Frequently asked questions

An effective SLA defines measurable service targets, assigns duties to both parties and sets out what happens when performance falls short. It also establishes response rules, financial remedies, escalation routes and a regular review cycle.

What should be included in a service level agreement?

An SLA should identify the services covered, the parties responsible and the operating hours that apply. It should define key terms such as outage, incident, maintenance window, business day and service credit.

It should also specify:

• Service scope and exclusions
• Availability and performance measures
• Support channels and operating hours
• Incident priorities and communication rules
• Response and resolution targets
• Customer and provider responsibilities
• Monitoring and reporting methods
• Maintenance and change procedures
• Security, data protection and continuity requirements
• Service credits, escalation and termination rights
• Review dates and dispute procedures

The SLA should state how each metric is measured, which data takes precedence and how either party can challenge a result. Clear definitions prevent disputes when an incident occurs.

What service levels and performance targets should an SLA define?

The SLA should set targets that the provider can measure consistently and the customer can verify. Common measures include availability, latency, successful transaction rate, capacity, incident response time, resolution time and mean time to restore service.

Each target needs a measurement period and calculation method. For example, availability should state whether planned maintenance, force majeure events or customer-caused failures count against the target.

Targets should reflect the service's operational importance. A payment service may need stricter availability and recovery targets than a monthly reporting portal, while a non-critical system may justify lower targets and lower fees.

How should an SLA set response and resolution times?

The SLA should classify incidents by impact and urgency, then assign a response target and a restoration or resolution target to each class. A critical outage affecting all users should receive faster handling than a minor issue with an available workaround.

A useful table should define:

The SLA should state when the clock starts, when it pauses and what counts as a response. It should distinguish acknowledgement, active work, restoration and permanent resolution because these are different outcomes.

It should also require updates at set intervals during major incidents. The provider should record the incident, actions taken, current impact and next update time.

What are the responsibilities of the service provider and customer in an SLA?

The provider should be responsible for delivering the agreed service, monitoring performance, maintaining support channels and reporting against the targets. The agreement should also require timely incident communication, access controls and corrective action after serious failures.

The customer should provide accurate information, authorised contacts and the access needed for diagnosis. It should follow documented operating procedures, maintain compatible systems and report incidents through the agreed channel.

The SLA should identify dependencies that either party controls. If the customer must approve a change, maintain a network connection or provide logs, the agreement should state how delays affect the relevant target.

How should an SLA handle service failures, credits and escalation?

The SLA should define the remedy for each material failure. Remedies may include service credits, management escalation, a root cause analysis, a corrective action plan or termination rights for repeated or severe failures. Common SLA remedies include credits, corrective action and termination rights.

A credit schedule should specify eligibility, calculation, maximum value, claim deadlines and whether credits apply automatically. The contract should also explain whether a credit is the customer's exclusive remedy or one remedy among several.

Escalation rules should name the roles involved, the time allowed at each stage and the information required. For a major incident, the provider should give a post-incident report covering the cause, service impact, timeline and actions that reduce recurrence.

The agreement should address exclusions carefully. It may exclude failures caused by customer changes, misuse, unsupported configurations or events outside the provider's reasonable control, but it should not use broad exclusions to undermine the service commitment.

How often should an SLA be reviewed and updated?

The parties should review the SLA at least annually and after major changes to the service, business needs, operating model or risk profile. High-change services may need quarterly reviews, while stable services may use a six-month or annual cycle. Many organisations review IT SLAs quarterly or twice a year.

Each review should examine performance reports, missed targets, incident trends, customer feedback, support demand and changes in dependencies. The parties should record agreed amendments with an effective date and named approvers.

A Monday checklist can confirm that:

• Every target has a definition, formula and measurement period
• Response and resolution clocks have clear start and pause rules
• Provider and customer duties have named owners
• Credits and escalation steps work in practice
• Exclusions and maintenance rules remain accurate
• Reports show actual performance against each target
• The next review date and approval route are recorded

Run this check

See how a site measures up on the basics before you act on any of this. Get a free website audit: enter a URL and an email, and we check the public pages on our servers, never logging in and never touching your files. The findings come back with the page, the reason and the fix.

Related

• Operations
• Data and Analytics