What goes into a service level agreement

A client sends you a draft services contract with an SLA schedule attached. Or you're the one providing services and you've agreed — in principle — to put your commitments in writing. Either way, you're looking at a document that turns general assurances into measurable obligations with consequences attached if you miss them.

An SLA (Service Level Agreement) is typically structured as a schedule to a broader services contract — a Master Services Agreement, Managed Services Agreement, or a standalone Service Agreement — rather than a freestanding document. The main contract handles fees, IP, confidentiality, liability and termination; the SLA schedule handles what you'll deliver, how you'll measure it, and what happens when you fall short. The two documents need to be read together: mismatches between your liability cap in the main contract and your remedy structure in the SLA create real exposure.

Scope and definitions

Every measurable commitment in an SLA depends on agreed definitions. Without them, disputes about whether you've met a target are almost inevitable.

Services covered: State exactly which services the SLA applies to — and what is excluded. If you manage infrastructure but not application-layer incidents, say so.
Key terms: Define "Downtime," "Business Day," "Business Hours," "Incident," "Emergency Maintenance," "Measurement Period." These terms appear repeatedly; if they're undefined, each side fills the gap differently.
Measurement period: Specify whether uptime is calculated monthly, quarterly, or annually. Monthly calculation is standard for IT services and is usually fairest to both sides.

The trap here is leaving "business hours" undefined. If your SLA promises a four-hour response time and the customer thinks that means 24/7 while you mean 9am–5pm AEST Monday to Friday, the gap is significant.

Service levels and metrics

This is the operational core of the document. Each commitment you make should be capable of being measured objectively, with a single agreed method of measurement.

Common metrics for technology and managed services businesses include:

Uptime percentage (e.g. 99.5% per calendar month)
Response time by incident severity (e.g. P1 within 30 minutes, P2 within 4 hours)
Resolution time by severity
First-contact resolution rate for helpdesk services

For each metric, specify the measurement tool or data source you'll use. If the customer can run their own measurement and reach a different number, you need a tiebreaker — typically, your monitoring data is authoritative unless the customer can demonstrate a material discrepancy.

Be realistic. The target that looks compelling in a sales conversation becomes a contractual obligation the moment the customer signs. Promising 99.99% uptime when your actual 12-month average is 99.6% creates a chronic breach situation before you've even started.

Availability and support hours

State when you're available and when you aren't. This is distinct from the metrics clause — it defines the hours within which your response and resolution commitments apply.

Standard hours (e.g. 9am–5pm AEST, Monday to Friday, excluding public holidays)
After-hours coverage, if any — and at what tier
On-call arrangements for critical (P1) incidents outside standard hours
Public holiday coverage — whose jurisdiction's holidays apply if you and your customer are in different states

Be specific about which public holidays apply. A Sydney-based provider and a Melbourne-based customer will disagree about what counts as a "public holiday" unless the contract names the jurisdiction.

Incident management

Define what an "incident" is and then tier your incidents by severity. Without this structure, every customer treats their problem as the most urgent thing you have.

A workable severity matrix looks like:

P1 (Critical): Service completely unavailable or core functionality down; response within 30 minutes, target resolution within 4 hours
P2 (High): Significant degradation but a workaround exists; response within 2 hours, target resolution within 8 hours
P3 (Medium): Non-critical issue, minimal business impact; response within 1 business day, target resolution within 5 business days
P4 (Low): Minor issues, cosmetic, or enhancement requests; response within 2 business days, scheduled for next maintenance cycle

Include examples at each tier — "P1 includes: the production database is inaccessible; the customer's online ordering system returns errors for all users." Examples reduce arguments about severity classification and help your support team apply the tiers consistently.

The variant counterparties push for is severity classification solely at the customer's discretion. Resist this. The customer declaring every issue a P1 undermines your entire operational model. The classification criteria should be objective or, at worst, jointly agreed.

Maintenance and planned outages

Planned maintenance is excluded from most uptime calculations, but only if you've done it right.

Define your standard maintenance window (e.g. Sundays 2am–6am AEST)
Set minimum notice periods for scheduled maintenance (typically 48–72 hours)
Define "Emergency Maintenance" — unplanned but necessary work — and whether it requires shorter notice (typically 4–8 hours)
State explicitly whether planned maintenance counts as "Downtime" for uptime calculations. Standard practice is to exclude it; make this express

If your SLA doesn't address maintenance windows, every scheduled update becomes a potential SLA breach. This is one of the most commonly overlooked clauses in standard templates.

Customer obligations and dependencies

You can only meet your commitments if the customer does their part. This clause is your carve-out when they don't.

Access requirements: The customer must provide timely access to systems, premises, or personnel needed to deliver the service
Compatible environment: The customer is responsible for maintaining equipment, software versions, or configurations that fall within your supported range
Prompt approvals: If your work requires customer sign-off at defined stages, delays from the customer's side pause the clock
Third-party providers: If part of the infrastructure sits with a third-party provider outside your control (e.g. the customer's internet service provider, a cloud platform), your obligations apply only to the components within your control

Phrase this as a condition on your commitments: performance targets do not apply to the extent a failure is caused by a customer act or omission, a force majeure event, or a third-party service outside your control. The customer will push to narrow this; the scope of your exclusion is negotiable, but some version of it is non-negotiable.

Service credits and remedies

When you miss a target, what happens? Service credits — a reduction in the next period's fees — are the most common remedy for SLA breaches in commercial services contracts.

Drafting choices that matter:

Calculation method: Credits typically scale with the severity of the miss. A common approach is tiered credit percentages against the monthly fee — e.g. 99.0%–99.5% uptime = 5% credit, 95%–99.0% = 10%, below 95% = 15%.
Cap: Aggregate service credits in any month are typically capped at a fixed percentage of the monthly fee (often 20–30%). Without a cap, a catastrophic outage could eliminate the entire contract value in credits.
Sole remedy: Include express language that service credits are the customer's sole and exclusive remedy for SLA breaches, unless the main contract provides otherwise. This is standard in B2B services contracts.
ACL interaction: If your customer is a "consumer" under the Australian Consumer Law (Schedule 2 of the Competition and Consumer Act 2010 (Cth)) — which captures services purchased for $100,000 or less — consumer guarantees under ss 60–62 apply by force of law and cannot be excluded. You can limit remedies in certain circumstances, but you cannot contractually override the guarantee itself. Get this language reviewed.

The trap to avoid is service credits that are so punitive they effectively make the contract uneconomic after a single poor month. Proportionate credits protect the customer without undermining the relationship.

Chronic breach and termination

Missing a single target is not the same as persistently failing to meet the service levels. Your SLA should address both — and give both parties a path out when the relationship has broken down.

Define "chronic breach": typically two or more SLA failures in any rolling three-month period, or failure of the same metric for three consecutive months
Require a remediation plan before termination rights are triggered — this gives you a chance to fix a structural problem before losing the contract
Give the customer a right to terminate for cause (without penalty) if chronic breach is not remediated within an agreed period

From your side, include a right to terminate if the customer's repeated failure to meet their obligations (see the customer dependencies clause) materially prevents you from performing.

Reporting cadence

Build accountability into the document. A monthly performance report keeps both parties honest and creates a written record of how the service is actually tracking — useful if a dispute arises later.

Monthly performance report: uptime achieved, incidents by tier, credits applied, any known issues
Quarterly service review: trends, root cause analysis of significant incidents, proposed changes to targets or process
Agreed data format and delivery method — email, shared dashboard, or portal

This clause also functions as an early warning system. A customer who receives monthly data showing consistent 99.4% uptime against a 99.9% target is being told, in advance, that there's a problem — rather than discovering it during a dispute.

Optional clauses worth considering

Escrow and continuity: If you hold critical customer data or run mission-critical systems, a data escrow or business continuity obligation gives the customer assurance that data is recoverable if the relationship ends.
SLA review mechanism: An express mechanism to renegotiate targets annually — tied to changes in service scope, customer growth, or infrastructure upgrades — keeps the SLA current without requiring a full contract renegotiation.
Version control: Note the SLA version and effective date on the face of the document. Multiple customers on different SLA versions is common; knowing which version governs which relationship matters when a dispute arises.
Security and privacy cross-reference: If you process personal information, cross-reference your Data Processing Agreement and Privacy Policy from the SLA rather than duplicating obligations — inconsistency between documents is a risk.
Liquidated damages: For high-value or critical infrastructure engagements, the customer may push for liquidated damages rather than service credits. This is commercially different and needs specific legal advice.

How Artificer Legal can help

Service level agreements sit at the intersection of operational reality and legal risk. The clauses that cause the most problems in disputes are rarely the technical ones — they're the scope exclusions, the customer dependencies, and the sole-remedy language that wasn't properly aligned with the main contract.

When we review or draft an SLA for a client, we look at the document alongside the master contract rather than in isolation. We check that your liability cap isn't undermined by uncapped service credits, that your customer-dependency carve-outs are broad enough to be useful, and that your sole-remedy clause is structured to withstand challenge under the Australian Consumer Law consumer guarantees and the unfair contract terms regime — which, since 9 November 2023, applies civil penalties to businesses that use standard form contracts with small business customers (fewer than 100 employees or annual turnover under $10 million) containing terms that cause significant imbalance and aren't reasonably necessary to protect legitimate interests.

We also push back on unrealistic targets when we see them. If you're committing to 99.99% uptime without 24/7 on-call coverage, you're creating a chronic breach position from the outset.

If you're putting an SLA in place — or reviewing one you've been asked to sign — contact Artificer Legal to work through it properly.

The customer dependencies clause

The customer dependencies clause is the most commonly stripped-out or watered-down provision in SLA negotiations — and it's the one that matters most when a dispute actually reaches a lawyer's desk. Most service failures in the real world involve some contribution from the customer: delayed approvals, unsupported software versions, internet connectivity outside your scope, or actions taken by the customer's own IT team. Without a clear, comprehensive carve-out, you're exposed for failures you couldn't prevent.

In summary: a well-drafted SLA defines your service scope and exclusions, sets metrics you can actually measure, tiers your incident response, handles maintenance and planned outages expressly, carves out customer-dependency failures, uses proportionate and capped service credits, addresses chronic breach and termination, and maintains a reporting cadence that creates a contemporaneous performance record. The SLA schedule and the main services contract need to be drafted as a pair — liability caps, sole-remedy clauses, and termination rights must be consistent across both documents.