Guide
Writing a service level agreement: uptime maths, response times and credits
A service level agreement, or SLA, puts numbers on a service: how much of the time it will be available, how quickly problems will be answered and what the customer gets if the provider misses the targets. Vague promises such as “high availability” cannot be checked. An SLA can, and that is why larger customers ask for one. This generator drafts the agreement and works out the downtime figures for you.
From a percentage to minutes
The key input is the monthly uptime commitment. Allowed downtime is the unavailable share of the period: 100 minus the uptime, divided by 100, times the minutes in the period. For a 30-day month there are 43,200 minutes, so 99.9% allows 0.1% of them, which is 43.2 minutes. A year has 525,600 minutes, so the same commitment allows 525.6 minutes, close to 8.8 hours. The tool prints this as a table for one day, a 30-day month and one year, so both sides can see what a figure like “three nines” means in practice. Leave the field empty and it uses 99.9; a value that is not a number is rejected.
The other parts
Define the provider, the customer, the service covered and an effective date. Describe scheduled maintenance that does not count as downtime, for example up to four hours a month, announced 48 hours in advance and carried out outside business hours. State the support hours and the response time for each of four severities: severity 1 for service down, 2 for a major feature impaired with no workaround, 3 for a minor problem or a workaround, and 4 for a question or request. A response is defined as an acknowledgement by a person who starts work on the problem, not a fix.
Service credits are typed one per line as the uptime below which a credit applies and the credit, as a share of that month’s fees. Finally, set how many days the customer has to claim a credit after the month ends.
A worked example
The first sample is Maple Cloud Ltd supplying the Maple Orders application to Harbour Goods Ltd with a 99.9% commitment. The table allows 1.4 minutes a day, 43 minutes in a 30-day month and 8.8 hours a year. Response times are 1 hour, 4 hours, 1 business day and 2 business days. Credits are 10% below 99.9%, 25% below 99.0% and 50% below 95.0%, claimed in writing within 30 days. The second sample raises the commitment to 99.95%, which cuts the allowance to 0.7 minutes a day, 22 minutes a month and 4.4 hours a year, and shortens the severity 1 response to 30 minutes.
Making the numbers honest
Do not promise precision you cannot measure. If your monitoring checks every five minutes, a commitment measured in seconds is not meaningful. Decide where uptime is measured, whether partial outages count, and which events are excluded, such as the customer’s own equipment or events beyond reasonable control. Make credits large enough to matter and small enough to afford, and check that the sole-remedy wording matches the liability terms of your main contract.
Limits
This is a general template, not legal advice. It covers a typical software-service SLA and does not deal with data protection, security commitments, step-in rights or sector rules. The agreement is only as reliable as the monitoring behind it, and credits do not replace the remedies of the main contract unless that contract says so.
Related tools
- Contractor Agreement Generator handles individual service providers rather than hosted platforms.
- Web Development Contract Generator covers building a site, which an SLA then supports once it is live.
- EULA Generator governs how end users may use the software that the SLA keeps running.
- Terms and Conditions Generator is the public-facing set of rules that sits beside a negotiated SLA.
Checked against the current version of the SLA Generator on .

