Every managed Odoo hosting proposal carries an uptime number. It is usually 99.9%, occasionally 99.95%, and it is often the least useful line in the document. The number tells you what the provider is willing to be measured on. It does not tell you how much downtime your team will actually feel, who decides when an outage started, or what happens on the morning nobody can log in.
An SLA is worth reading properly, because the parts that decide your experience are rarely the headline percentage.
What the percentages mean in minutes
Uptime commitments become easier to judge once you convert them into time. Over a 30-day month, the allowed downtime works out roughly as:
- 99% allows about 7 hours and 12 minutes
- 99.5% allows about 3 hours and 36 minutes
- 99.9% allows about 43 minutes
- 99.95% allows about 21 minutes
- 99.99% allows about 4 minutes
Two details move these figures more than the percentage itself. The first is the measurement window. An SLA measured annually lets a provider absorb one long outage and still report compliance, because the error budget resets once a year instead of twelve times. Monthly measurement is stricter and more honest, so check which one you are being offered.
The second is what is actually being measured. An HTTP check against the login page is not the same as confirming that a sale order can be confirmed or an invoice posted. A database that serves the login screen while background jobs are stuck is technically up and practically unusable. Ask what the probe does, how often it runs, and how many consecutive failures it takes before the clock starts.
Read the exclusions before you read the number
Every SLA carves out categories of downtime that do not count. Typical ones include:
- Planned maintenance inside an announced window
- Downtime caused by your own changes, such as a customization pushed straight to production or an import that locks the database
- Third-party dependencies: payment gateways, e-invoicing portals, mail relays, external APIs
- Network problems beyond the provider's edge, including your own office connectivity
- Force majeure and upstream cloud provider incidents
Most of these are reasonable. A provider cannot be accountable for an outage at a tax authority portal. But the exclusions, not the percentage, are what define the promise. A 99.99% SLA with unlimited planned maintenance windows is weaker than a 99.9% SLA that counts every minute your users cannot work.
Service credits are not compensation
When an SLA is missed, the usual remedy is a service credit: a percentage of the monthly fee returned, capped at some share of that month's invoice, and typically claimable only if you file within a set number of days. That is a governance mechanism, not insurance. For a distribution business, a full day without order entry costs far more than a month of hosting. Read credits as a signal that the provider is willing to be held to something, and plan your continuity separately.
The clauses that matter more than uptime
In practice, the questions that decide how bad an incident feels are these:
- Recovery point objective. How much data can you lose in the worst case? Daily backups mean up to a day of re-entry. Point-in-time recovery narrows that to minutes.
- Recovery time objective. How long does a restore actually take on a database your size? Ask for evidence of a tested restore, not a backup policy. A backup nobody has ever restored is a hypothesis.
- Response versus resolution. A one-hour response target means someone acknowledges the ticket, not that the system is back. Check the severity definitions and whether coverage is 24/7 or business hours in a specific time zone.
- Maintenance notice. How much warning do you get, and can a window be deferred during month-end close or a payroll run?
- Staging environments. Most production incidents come from changes, not hardware. A plan that includes a staging or sandbox copy prevents more downtime than a stricter uptime clause.
Where Plemo sits
Plemo provides managed Odoo hosting with automated backups, point-in-time recovery, monitoring, and staging and sandbox environments, so changes can be rehearsed on a copy before they touch production. The reason we emphasize those specifics over a headline percentage is simple: they are what you rely on during the hour something goes wrong. For engagements where support scope and response targets need to be written down formally, our managed support and SLA service covers that separately from hosting itself.
Questions to ask before you sign
- Is uptime measured monthly or annually, and against what probe?
- Which categories of downtime are excluded, and is planned maintenance capped?
- What is the backup frequency, the retention period, and the point-in-time recovery granularity?
- When was a restore last tested on a database of comparable size, and how long did it take?
- What are the severity levels, the response targets for each, and the hours of coverage?
- Who is the escalation contact after the first response target is missed?
A provider who answers those six questions clearly is telling you more than any percentage can. The number is a floor for accountability. The operational detail underneath it is what you actually buy.