Availability (SLA)
Availability (SLA) is the share of time a provider guarantees an ERP system will be usable, defined in the Service Level Agreement and usually stated as a percentage such as 99.9%. It sets how much downtime is contractually permitted and what happens if that promise is broken.
Availability (SLA) describes the percentage of a period during which an IT service – such as a cloud ERP – is actually reachable and usable, and the value the provider contractually guarantees in a Service Level Agreement (SLA). An SLA of 99.9% means the system may be down for at most around nine hours per year on average. Availability is therefore not a technical detail but a core metric for how reliably a business can depend on its system.
The Service Level Agreement is the contract between provider and customer that fixes the promised availability, the measurement period, exceptions (such as scheduled maintenance) and the consequences of falling short – usually credits. Especially with cloud and SaaS ERP, where the provider runs the operation, the availability guaranteed in the SLA is the central promise against which operational reliability and trust can be measured.
At a glance
- Availability = the guaranteed share of time in which the system is usable
- Stated as a percentage; "three nines" (99.9%) ≈ 8.8 h of downtime per year
- Defined in the Service Level Agreement (SLA), including measurement period and exceptions
- Scheduled maintenance windows usually do not count as downtime – check the contract detail
- A breach normally triggers service credits, rarely full compensation for damages
What availability (SLA) actually measures
Availability is calculated as the ratio of actual uptime to the agreed total time of a measurement period – typically a month or a year. In simplified form the formula is: availability = (total time − downtime) / total time. If a system is down for three hours in a 30-day month, that works out to roughly 99.58% availability. What matters is how the contract defines "downtime": only complete unreachability, or also noticeable performance drops and partial outages of individual functions.
The guaranteed values usually follow a scale of "nines". The jump from one nine to the next is substantial: each additional nine cuts the permitted downtime by roughly a factor of ten – and makes operation more expensive to match, because redundancy, contingency planning and monitoring become more demanding.
From 99% to 99.99%: what the "nines" mean
99% ("two nines") allows around 3.65 days of downtime per year – far too much for an ERP in productive use. 99.9% ("three nines") corresponds to about 8.8 hours of yearly downtime and is the common standard among many cloud ERP providers. 99.99% ("four nines") lowers the permitted downtime to around 52 minutes per year and is usually guaranteed only for business-critical systems or at extra cost. It is always important to know which period the percentage refers to – a monthly target is less forgiving of a single long outage than an annual one.
Components of a robust SLA
A meaningful Service Level Agreement consists of more than a single percentage. It names the scope (which services and components are covered), the measurement period and method, the definition of an outage, and how scheduled maintenance is handled. Announced maintenance windows are often excluded from the availability calculation – anyone who overlooks this overestimates real-world usability.
Response and recovery times belong here as well. The response time (RTS) states how quickly the provider reacts to an incident; it must not be confused with availability itself. In addition, metrics for recovery duration and the maximum tolerated data loss are often agreed – topics that are secured through the disaster recovery concept and regular backups. Finally, the SLA governs the legal consequence of falling short, in practice usually tiered service credits rather than full compensation for damages.
Why availability (SLA) matters for the business
An ERP drives order processing, warehousing, invoicing and often the connection to shops and marketplaces. When it stands still, nothing can be picked, invoiced or synchronised – every hour of downtime directly costs revenue and trust. The guaranteed availability translates this risk into a plannable figure: it indicates how much standstill a business can expect per year and how much buffer it must build into its processes.
For ERP selection, the SLA is therefore a hard comparison criterion alongside feature scope and cost. Two offers at the same price can provide very different operational reliability if one guarantees 99.5% and the other 99.9%. Anyone with strongly seasonal sales should also check whether maintenance windows fall outside their own peak times and whether the credits are even noticeable relative to the actual damage from an outage.
Availability in cloud vs. on-premise ERP
With cloud and SaaS ERP, the provider is responsible for servers, data centre and maintenance; availability is part of its service promise and fixed in the SLA. The customer benefits from professional redundancy and monitoring but gives up control and depends on the quality of the contract. With on-premise operation, by contrast, the responsibility lies in-house: availability is then not a guaranteed value but the result of one's own infrastructure, backups and emergency processes.
A common misconception: the provider's SLA availability only covers its part. If your own internet line fails, the cloud ERP is unreachable despite perfect provider uptime. The availability experienced in practice is therefore the chaining of several links – provider, network, end devices – and is always only as good as the weakest of them.
Distinction: availability, reliability and redundancy
Availability states what percentage of the time a system is running. Reliability, by contrast, means how rarely it fails at all (frequency of incidents), and maintainability how quickly it is running again afterwards. Redundancy – keeping critical components duplicated – is one of the most important means of technically achieving high availability, but is not identical to it. An SLA describes the result (availability), not necessarily the technology behind it.
What to watch for in SLA contracts
Before signing, it pays to read the fine print: is availability measured per month or per year? Do partial outages and scheduled maintenance count? How and by whom is it measured, and must the customer report an outage themselves to be entitled to a credit? Are the credits capped as a percentage, and do they stand in a realistic relation to the possible damage from an outage?
It is also advisable not to view the SLA in isolation but together with support services, backup and disaster recovery commitments, and the hosting location. A high percentage is of little use if recovery and data restoration take a long time in an emergency. Especially in the DACH region, the data centre location and GDPR compliance also play a role, which is why availability commitments and data protection questions can sensibly be assessed together in the operating concept.
Example
Example: 99.9% during the Christmas season
An e-commerce retailer running cloud ERP has an SLA of 99.9% on a monthly basis. In November the system is down for two hours on a Sunday evening because of a database problem at the provider. With around 720 hours in the month, two hours of downtime equals roughly 99.72% – so the 99.9% promise is breached.
The retailer reports the incident on time and, under the contract, receives a service credit of 10% of the monthly fee. The actual damage, however – stalled orders and unsynchronised stock in the run-up to Christmas – is far higher than the credit. The lesson: an SLA promise only partly caps the risk financially; what matters is whether maintenance windows fall outside peak times and how quickly the provider is operational again after an incident.
Frequently asked questions
Matching ERP systems
Related services
Questions about Availability (SLA) in your ERP project?
We advise vendor-neutrally – and implement it ourselves on request.