SLA Calculator
Turn an uptime percentage into allowed downtime, convert downtime back to uptime, or find exactly when a support ticket is due under a business-hours SLA. Free, no sign-up.
- Daily
- 1m 26.4s
- Weekly
- 10m 4.8s
- Monthly
- 43m 49.8s
- Quarterly
- 2h 11m 29.4s
- Yearly
- 8h 45m 57.6s
Uses a 365.25-day year, so a month is 30.44 days and a quarter is 91.31 days on average.
Free. No sign-up. Everything is calculated in your browser, nothing you enter is sent anywhere.
How it's calculated
- Allowed downtime
- Downtime = period length x (1 - uptime % / 100)
- Uptime from downtime
- Uptime % = (1 - downtime / period length) x 100
- Period lengths
- Day 24h Week 7d Month 30.44d Quarter 91.31d Year 365.25d
- Response due time
- Due = received time + target, counting only business days and hours
Worked examples
SLA calculation examples
Common uptime targets and a response-time SLA that runs over a weekend.
A standard 99.9% uptime commitment.
Uptime target 99.9%.
0.1% of the time can be down: 1m 26s a day, 43m 50s a month, or 8h 46m a year.
A premium tier promising 99.99%.
Uptime target 99.99%.
Only 4m 23s of downtime a month, or 52m 36s a year. One slow deploy can use the whole monthly budget.
An incident took the service down for 45 minutes this month.
45 minutes of downtime per month.
1 - 2,700 / 2,629,800 seconds gives 99.897% uptime for the month. That misses a 99.9% SLA.
A 4 business hour first response target, Monday to Friday, 9:00 to 17:00.
Ticket received Friday at 15:00.
Two business hours run out Friday at 17:00. The clock pauses for the weekend and the last two hours run Monday 9:00 to 11:00, so the reply is due Monday at 11:00.
Writing a good SLA
What to decide before you commit to a number
The math is simple. The definitions around it are where most SLA disputes start.
Each extra nine cuts downtime tenfold
99% allows about 7 hours 18 minutes a month, 99.9% about 44 minutes, 99.99% about 4 minutes. Cost and effort rise sharply with each nine.
Define the measurement window
A monthly SLA resets every month, a yearly one lets a bad month be offset. State the period, and whether planned maintenance counts, in the agreement.
Response SLAs should say business or calendar hours
"4 hours" means very different things at 16:00 on a Friday. Spell out your business hours, days and timezone, and how holidays are handled.
Measure first response, not resolution, unless you mean it
Most support SLAs promise a first reply time. Resolution time depends on the problem and is harder to guarantee, so it usually gets a separate, looser target.
FAQ
Questions people ask
How do you calculate allowed downtime from an uptime SLA?
Multiply the length of the period by (100% minus the uptime percentage). For 99.9% over a 30.44-day average month that is 2,629,800 seconds x 0.001, about 43 minutes 50 seconds.
How much downtime is 99.9% uptime?
About 1 minute 26 seconds a day, 10 minutes a week, 43 minutes 50 seconds a month and 8 hours 46 minutes a year.
Why does the monthly figure use 30.44 days?
It is the average month length over a 365.25-day year, so the monthly numbers add up to the yearly one. A 30-day or 31-day month changes the monthly budget by a minute or so at 99.9%.
How does the response time calculator handle weekends and evenings?
The SLA clock only runs during the business days and hours you set. A ticket that arrives outside them starts counting at the next opening time. Public holidays are not excluded, so adjust for them yourself.
What is a typical support response SLA?
It varies by plan and channel. Email support often promises a first reply within 4 to 24 business hours, while live chat is measured in seconds or minutes. Premium tiers usually get shorter targets.
Is anything I enter stored?
No. The calculator runs entirely in your browser. Nothing you type is sent to a server or saved.
More free tools
Hit your response SLA at 3am, without a night shift.
Bund AI replies to customers on web chat and email in seconds, any hour of the day, from your own help content. It resolves routine questions itself and hands the rest to your team with the full context, so the first response never waits for business hours.