Pandora Tech Blog

What is an SLA and how is it calculated?

by | Last updated Aug 20, 2026 | Tech

Contents:

In the Star Trek: The Next Generation episode Relics, La Forge discovers Scotty’s secret and the reason behind his reputation as a miracle-working engineer in the legendary original series. Whenever someone asks him how long a repair will take, he multiplies his real estimate by four. If he finishes early, the genius has done it again, and if things get complicated, he still manages to finish on time anyway. It is the classic IT trick that becomes useless as soon as someone writes that promise in a document next to a number. That document is the SLA, the Service Level Agreement.

It establishes three things:

  • What level of service is expected from what we provide.
  • How it is measured.
  • What happens if it is not met.

In this way, the SLA becomes the “law” that any organization providing services must comply with in IT management for someone else… and it prevents us from improvising like Scotty and looking like geniuses, forcing us instead to stick to what is written there.
That is why we are going to get closely acquainted with these laws of our professional field, since the benefits will depend on them.

What is an SLA?

As always, we need to start by opening the dictionary, and an SLA is the agreement in which a provider and a customer define the committed service level and how it will be verified.
“Physically,” it can be a contractual appendix, an internal document between the IT department and the rest of the company, or a two-paragraph page in an integrator’s proposal.
It is the conditions expressed in measurable terms, rather than a lawyer’s stamp, that make something an SLA, so any reasonably serious one will establish:

  • Services included. Corporate email, invoicing app, e-commerce provisioning… It can include almost anything, but the more vague the scope is, the more arguments there will be during the inevitable first outage.
  • Expected service level. Such as 99.9% monthly availability, an initial response to critical incidents within 30 minutes, latency below a certain threshold… The specific indicator will vary, but it must be agreed upon.
  • How it is measured. From where, how often and which tool collects the numerical truth. Without this, the SLA is just literature and nothing more.
  • Over what period. Monthly, quarterly, annually… The period changes the result more than it may seem, as we will see later with actual figures.
  • Responsibilities of each party. Including those of the customer, who often forgets that opening a ticket with sufficient information is also part of the deal. This way, the blame game becomes a two-way street rather than something directed only at the technical manager.
  • Consequences of non-compliance. An SLA is a “blood pact,” not a diary of good intentions, which is why it includes real consequences for failing to meet it. The most common are penalties, discounts, an action plan or a service review.

Let us look at a simple example.
We hire an MSP (managed service provider) to manage our virtualized servers, and the signed SLA states that:

  • The infrastructure will be available 99.9% of the time each month.
  • Critical incidents will be addressed within 30 minutes or less, 24×7.
  • Maintenance windows will be announced 72 hours in advance.
  • A monthly report containing the data will be delivered.

Thanks to this, the conversation revolves around tangible indicators rather than subjective impressions.

What is an SLA used for?

So that both parties can argue by throwing data at each other instead of perceptions, a battle nobody ever wins, but also to optimize the relationship and the work.
In this way, the SLA gives the provider an objective criterion for delivering its service. It knows what it needs to maintain, can size its team appropriately and has solid arguments during those “this is running slowly” calls when the data shows that the service was available 99.97% of the month, above the 99.9% committed in the SLA from the example.
Without an SLA, customer expectations grow to infinity and beyond, always ending with: “Well, I thought this was covered.”
On the other side of the trench, it makes clear to the customer what they can expect and, above all, how to verify it.
This mainly affects managed service providers (MSPs), because their product is the service level itself.
All of this also affects internal IT departments because, even when there are no financial penalties involved, an SLA prevents technology priorities from being dictated by whichever ticket shouts the loudest.

What an SLA usually includes

It is impossible to cover every requirement that has ever been included in an agreement of this kind, but there are elements that appear again and again in SLAs, and their absence can prove costly.

  • The scope of the service. In other words, which systems, applications and components are included and which are not, something equally important.
  • The committed availability. Expressed as a percentage, together with its measurement period and calculation method (we will see an example).
  • The coverage schedule. Because although the customer may be short-sighted when it comes to distinguishing these things, promising “24×7” is not the same as promising “Monday to Friday from 9 a.m. to 6 p.m.” Many apparent breaches are actually incidents opened outside the hours agreed in the SLA.
  • First response time. Or how long it takes someone to take charge of whatever fire breaks out.
  • Resolution time. How long it takes to put out the previous fire and get the service working again. Be careful, because confusing this with the previous point is a classic mistake, so it is important to distinguish them clearly in the SLA.
  • Priorities and classification. With criteria for deciding what is critical, high, medium or low, including specific examples. Otherwise, there is only one classification for the customer: “everything is critical.”
  • Scheduled maintenance. This determines the planned maintenance windows, the advance notice required and whether they count toward the SLA availability calculation, another of those seemingly minor details that make all the difference.
  • Measurement and reporting method. Defining which tool generates the data, with what granularity and in what format it is delivered.
  • Consequences of non-compliance. Whether these involve financial compensation, future discounts, service reviews, a signed improvement plan…
  • Escalation procedure. What happens when the first support level does not have a fire extinguisher big enough? We need to define that escalation with names, channels and timeframes.
  • Exclusions. Such as force majeure events, third-party failures, carrier outages or changes requested by the customer itself.

    • These exclusions deserve a paragraph of their own, because they are the part of the document that most closely resembles Homer’s monkey’s paw in The Simpsons, an episode in which wishes come true exactly as they are asked for and never as expected.

It is essential to understand that an SLA with vague exclusions literally grants what is written, not what we imagined, so if the agreement excludes “incidents caused by third parties” exactly as written, then the cloud provider, Internet carrier or firewall manufacturer are third parties, and almost any outage can fit through that door.
Frameworks such as ITIL in IT service management have been organizing these elements for years, so it makes sense to rely on them, if only to avoid reinventing the tedious wheel of priority classification every time we sign a contract.

Common metrics in an SLA

Let us start by clearing up THE most widespread misunderstanding on the subject, because an SLA is not just an availability percentage with a contract wrapped around it to fill the page. Availability is simply one more metric and, in many services, it is not even the one that best reflects the actual user experience.
That is why the metrics we will most often see in an SLA include:

  • Availability or uptime. Calculated as the percentage of time the service has remained operational within the period we define, whether monthly or otherwise.
  • First response time. As we saw earlier, this is the time from when the ticket is opened until a technician picks up the mess and takes responsibility for it. Smart SLAs understand that this is the metric users perceive most strongly, and perception is the most important thing in this world obsessed with appearances, because silence when asking for help is what really drives people mad.
  • Resolution time. From the opening of the incident until the service is restored.
  • MTTR. Meaning Mean Time To Repair, the average repair time over a given period. It gives us a picture of the team’s actual capacity over time rather than in isolated cases.
  • Latency or performance. Essential in web applications, APIs or data services, because a system that responds in eight seconds can be technically available and practically unusable at the same time.
  • Incident rate. Measuring how many incidents are opened per period and of what type. This helps detect things such as whether the issue lies in operations or in design.
  • Compliance percentage. Calculating what proportion of incidents were handled and resolved within the committed timeframes.

As is usually the case in the real world, the combination of several metrics is what makes an SLA useful. A service may meet its 99.9% availability target and still be a disaster if, every time it fails, nobody responds for six hours.

SLA and uptime: differences

Earlier, I mentioned a common case of confusing “the part for the whole” when talking about availability and SLAs, and this is another of those topics that deserves its own section.
Uptime or availability is a metric that is monitored, a “part” of the “whole” that is the SLA, but it is not the SLA itself. The SLA is the complete agreement that includes uptime as one of its metrics alongside response times, resolution times, coverage hours and everything else we have analyzed.
That said, among SLA indicators, availability is usually the queen. Uptime can be measured and managed without an SLA and, in fact, this is standard practice in any IT operation, but having an SLA without the ability to measure uptime is like signing a check without looking at the account balance.

How an SLA is calculated

Although the metrics in a service level agreement go beyond the availability of the contracted service, almost everything revolves around it, and it is the first thing to consider when calculating an SLA.
In this case, and without setting a precedent in IT, we will not need NASA-level calculations, because a little basic arithmetic will be enough:

Availability = (available time / total measured time) × 100

Let us apply it with an example. A 30-day month has 720 hours, that is, 43,200 minutes. If the service was down for 65 minutes, then:
Availability = (43,200 − 65) / 43,200 × 100 = 99.85%
With a commitment of 99.9%, there is a breach that month because the 99.9% margin in a 30-day month is approximately 43.2 minutes, but here we have used 65.
However, let us now analyze the interesting part, which shows why it is essential to define availability precisely in the SLA.
Suppose that 30 of those 65 minutes occurred during a scheduled two-hour maintenance window, announced in advance and excluded from the calculation according to the agreement.
In this case, the total measured time drops to 43,080 minutes (after subtracting the two hours from the measurement, 120 minutes) and the downtime counted under the SLA falls to 35 minutes:
(43,080 − 35) / 43,080 × 100 = 99.92%
Same month, same outages, but now the result changes from non-compliance to compliance.
In this example, there would be no trick on the provider’s part, and the SLA makes that clear. That is why the fine print concerning exclusions and maintenance windows carries as much weight as the percentage itself, and why it is worth reading how large companies word these agreements, from the AWS service level agreements to the Microsoft Online Services SLAs, where calculation methods, exclusions and claim procedures take up more space than the availability figure itself.
As a basic reference, this is what each percentage translates into in terms of permitted downtime, based on 30-day months and 365-day years:

Availability

Per month

Per year

99%

7 h 12 min

3 days 15 h 36 min

99.9%

43 min 12 s

8 h 45 min 36 s

99.99%

4 min 19 s

52 min 34 s

This shows why each additional nine multiplies the price. Moving from 99% to 99.9% is a matter of disciplined operations, but moving from 99.9% to 99.99% requires real redundancy, automatic failover and a team capable of reacting within a monthly downtime budget of just four minutes.
This is where too many sales teams promise that extra nine, which may not seem like much to non-technical eyes, but which our infrastructure may easily be unable to sustain.
The other SLA metrics are evaluated against individual cases rather than against the service clock, such as the incidents we handled within the committed timeframe (divided by the total and multiplied by one hundred). In those cases, the arithmetic is the same, although we are counting headaches instead of minutes.

Practical example of an SLA in IT

To bring all these concepts down to earth, let us look at a typical agreement for a business application, summarized in its table of conditions.

Concept

Commitment

Service

Business management application

Availability

99.9% monthly

First response (critical)

30 minutes

Target resolution (critical)

4 hours

Coverage for critical incidents

24×7

Scheduled maintenance

Monthly window announced 72 h in advance, excluded from the calculation

Report

Monthly, with details of outages and incidents

The lesson from this table is that none of its rows means very much on its own.
For example, that 99.9% without 24×7 coverage leaves nights unprotected. Or a four-hour resolution time without a clear definition of what that “critical” in parentheses actually means turns into a negotiation every time the phone rings.
The key is that an SLA is the complete set of conditions and works when all of them point in the same direction.

Support SLA and response times

In support and helpdesk environments, we have a clear example of how the focus of an SLA shifts from availability to time, with four concepts that should not be confused.

  • First response. The time until a technician confirms that the incident has been received and takes ownership of it. Be careful, because this does not imply a solution, only that someone has taken the wheel of the car as it heads over the cliff.
  • Response during the incident lifecycle. Let us consider the forgotten metric that prevents the most complaints, which defines how often the incident status is updated while it remains open. The customer wants to feel that the person holding the wheel is doing more than just gripping it.
  • Resolution time. The time that passes until the service is operational again, with or without a definitive solution. It is worth distinguishing between a temporary workaround and full closure, because the customer does not experience them in the same way.
  • Escalation. When an incident moves up a level, who gets handed the problem and what automatic process implements it, because if escalation depends on someone remembering to do it… then it is not really escalation.

In addition, all of this must be supported by a priority scheme, or the IT service provider will spend its life running around like a headless chicken.
The usual approach here is to cross impact (how many people or how much of the business is affected) with urgency (how long something can wait before everything starts falling apart) to determine the level. We then associate specific timeframes with each level.
This is where an incident and SLA management tool stops being a luxury, because the clocks need to run automatically within the ticketing system, pause when the incident is waiting for information from the customer, and issue warnings before the deadline expires.

Difference between SLA, SLO and SLI

One letter makes all the difference. Zara managed to have the Zora trademark registration cancelled in India because the similarity could confuse buyers, while Google rushed to secure domains such as “Goggle” to prevent typo traffic from being redirected to malicious domains or sites with misleading advertising.
The same thing happens here with three acronyms that are confused because of that single vowel, but to avoid that…

  • SLI (Service Level Indicator): the indicator being measured, the raw data, such as the percentage of requests served correctly.
  • SLO (Service Level Objective): the internal target the team wants to achieve.
  • SLA: what we have already seen, the agreed commitment with the customer and its associated consequences.

The practical rule is that the SLO should always be more demanding than the SLA, so that IT has room to react before failing to meet what was promised.
All of this stems from the practice of Site Reliability Engineering, which Google formalized in its chapter on service level objectives, a subject with far more depth than I can cover here without turning this into the lost volume of Harry Potter.
For those who want the full explanation, it is available in our guide on the differences between SLA, SLO and SLI.

How to monitor SLA compliance

An SLA that is checked at the end of the month by asking around how things went is a satisfaction survey, but to paraphrase Malraux (very) loosely, compliance must be continuous or it will not be compliance at all, and its measurement must also be uninterrupted.
That implies several things, and all of them at the same time.

  • Availability needs to be measured constantly and from a point that makes sense, because checking a web service from the same data center that hosts it is like having the student grade their own exam.
  • It is necessary to record incidents with reliable timestamps for opening, assignment, escalation and closure.
  • We need to keep historical data, because a single month’s figures are not enough to detect progressive degradation.
  • Since all of this is intended to improve management and is not merely a matter of vanity, alerts are essential to trigger when the remaining margin approaches the limit.

Once server and infrastructure monitoring is in place, compliance becomes an automatic calculation by period, and the report stops being an unpleasant manual task on day 30 of the month.
And here is another detail that is often overlooked: the monitoring system can also go down.
If our watchdog goes blind for two hours, that gap has to mean something, and it is advisable to decide in advance whether it counts as SLA downtime or as unknown data.
Leaving that gap to the discretion of whoever writes the report is an unnecessary temptation, because what is most convenient will prevail instead of what is most accurate.

How Pandora FMS helps measure SLAs

We believe in Pandora FMS above all else, because it is the materialization of more than 20 years of our experience, but don’t worry, because I am not a salesperson and I am not going to pretend to be one, so let us talk about facts rather than sales pitches.
Does Pandora FMS help manage SLAs?
Absolutely yes.
Pandora FMS solves the challenge of calculating SLA compliance based on objective data collected from the infrastructure.
For Pandora, there is no additional layer of makeup, nor does it add one, which makes it possible to extract the truth that matters to both parties signing the service contract. In this way, Pandora FMS acts as watchdog, analyst, repository and notary.
The SLA reports allow us to define the target, whether by module or service, as well as the measurement period and the intervals considered valid. With that information, they return the percentage achieved, together with details of every outage experienced during the period.
The technical documentation on report types explains the variants available to us and how each one behaves with historical data.
With all that in place, the most commonly used SLA features in Pandora FMS are:

  • Activity periods. Restricting the calculation to the agreed coverage hours so that an outage at 3:00 a.m. does not penalize an SLA that, according to the contract, must be measured from 9 a.m. to 6 p.m.
  • Planned maintenance. Service downtime windows are declared in the system and the report counts them as valid time, so they do not penalize the SLA. Exactly what was required in the calculation example discussed above.
  • Service view. The SLA can be defined for a composite service and not just for a single machine, even assigning weights to each element. That is where the difference lies between evaluating a server and measuring what really matters to the business.
  • Historical data and trends. Data in Pandora FMS is stored so that periods can be compared and gradual degradation can be detected, the kind that does not trigger an alarm but eats away at our margin month after month.
  • Scheduled reports. The monthly report is generated and sent automatically in the specified format, making reporting automatic and sustainable when managing forty customers.

That said, Pandora FMS does not perform magic (yet) and it does not replace a well-drafted agreement. If the SLA defines objectives that nobody can measure, even the best tool will only document with precision that nobody knows whether anything is actually being met.
Which brings us to the next fundamental point, because a tool is only as good as the process behind it, so let us see how to optimize it.

Best practices when defining an SLA

This is the moment of truth (both for the customer and the IT provider), when we do not want to trap ourselves in a Faustian bargain that looks great on paper but will come back to bite us in day-to-day operations.
To avoid this, we should:

  • Commit only to measurable metrics. Because if there is no automatic way to obtain the data, that clause should not be in the contract.
  • Write down how each indicator is calculated. This includes the formula, data source, measurement period and measurement point. Two parties with the same figure but different methods for obtaining it will end up arguing.
  • Clearly define the measurement period. A 40-minute outage means 99.91% monthly availability and, at the same time, 99.60% weekly availability. Which of the two periods counts? Because with the same outage we may either comply or fail to comply depending on the period considered, so this is never merely an administrative detail.
  • Define exclusions explicitly and precisely. Because simply saying “third-party failures” is that blank check I mentioned at the beginning.
  • Clearly separate response from resolution. Since they are different commitments involving different teams, costs and indicators.
  • Review service levels whenever the service changes. If we migrate to the cloud, the number of users grows significantly or we upgrade the equipment, these new circumstances invalidate the original assumptions that were signed, and these eventualities must be specified in the contract.
  • Avoid objectives that cannot be monitored. This is the Prime Directive that summarizes all the previous ones.

And from experience, here is a small piece of advice that is not usually mentioned.
Let us not promise the extra nine that our indicators cannot sustain. It is tempting, but no, stop. Maintenance Tuesdays in any MMO have been teaching the same lesson for twenty years, proven across millions of players: a scheduled, predictable and properly observed outage generates far fewer complaints than ten minutes of unexpected downtime.
We have written more about the balance between what is promised and what is sustainable when discussing how to reduce support hours without losing SLA compliance, increase IT operational efficiency, as well as in our guide on SLA types and best practices.

Frequently asked questions

Let us reconstruct the map of the territory we have covered through the most common questions about it:

What does SLA mean?

Service Level Agreement, the document that defines what level of service is committed to, how compliance is measured and what happens if that commitment is not met.
An SLA can be signed for many different activities, but for what concerns us here…

What is an SLA in IT?

The formal agreement that regulates the level of an IT service and details the percentage of system availability, incident response times, coverage hours and the way compliance is verified.
The SLA applies both to external providers and to internal IT departments.

How is an SLA calculated?

Compliance is measured according to the various key indicators defined within it, which may vary, but when most people ask this question, they are actually thinking about availability and how to evaluate it, since it is usually one of the main components of the overall SLA.
Availability is calculated as available time divided by total measured time, multiplied by 100. Agreed exclusions, such as scheduled maintenance windows, are deducted from that total time.
The remaining SLA metrics, such as possible response times, are calculated as the percentage of cases handled within the committed timeframe.

What is the difference between SLA and uptime?

Following on from the above, uptime is a metric, the percentage of time the system has been available, while the SLA is the complete agreement.
It may include uptime among its indicators, along with response times, resolution times and coverage.

What is a response time SLA?

The commitment regarding how long it takes to respond to an incident, depending on its priority.
A distinction is usually made between first response, updates during the incident lifecycle and resolution, with different timeframes for each level of criticality.

What happens if an SLA is breached?

It depends on what was agreed in the contract. Financial compensation or discounts on the invoice are common, although in many internal agreements the consequence is a documented action plan and a service review.

What is the difference between SLA, SLO and SLI?

The SLI (Service Level Indicator) is the indicator being measured, the SLO is the internal objective for that indicator, while the SLA is the commitment agreed with the customer.
The SLO should obviously be more demanding than the SLA, so that IT has some margin when dealing with the customer.

The agreement is the easy part

As we have seen, an SLA turns expectations into commitments with a number, a period, a calculation method and consequences for non-compliance. This changes the conversation between provider and customer because we stop arguing about whether the service is “working well” in vague terms and start checking agreed objective data that provides the real answer.
What supports that data is continuous monitoring, historical records and reports, because without them the agreement is nothing more than an empty promise presented in table format.
Before SLAs, Scotty could multiply his engineering estimates by four because nobody measured them on the Enterprise, but as soon as someone brings out the ruler… the service stops being a reputation trick and becomes pure engineering that is calculated, monitored and defended with data.

Shares