An MQTT broker SLA is a provider's written commitment about availability, and the fine print matters as much as the headline percentage. This article translates common uptime targets into real downtime minutes, explains what SLAs usually cover and exclude, and shows how to design your devices and applications so they cope gracefully with the downtime any SLA still allows.
What an SLA Is, and What It Is Not
A service level agreement is a contractual document. It defines a measurable target, usually monthly availability, how availability is measured, and what the provider owes you if the target is missed. Three related terms are often confused:
- SLI (service level indicator): the measured value, such as the percentage of successful connection attempts.
- SLO (service level objective): the internal target a team aims for, often stricter than the SLA.
- SLA (service level agreement): the external, contractual promise with consequences, usually service credits.
The crucial point: an SLA does not prevent outages. It defines how much unavailability is acceptable and how you are compensated when there is more. Your system still has to handle the downtime the SLA permits.
Uptime Percentages in Downtime Minutes
The differences between "nines" are larger than they look. The table uses an average month of about 30.4 days and a 365-day year.
| Availability | Downtime per month | Downtime per year |
|---|---|---|
| 99% | about 7 hours 18 minutes | about 3 days 15.6 hours |
| 99.5% | about 3 hours 39 minutes | about 1 day 19.8 hours |
| 99.9% | about 43.8 minutes | about 8.8 hours |
| 99.95% | about 21.9 minutes | about 4.4 hours |
| 99.99% | about 4.4 minutes | about 52.6 minutes |
| 99.999% | about 26 seconds | about 5.3 minutes |
Moving from 99.9% to 99.99% cuts allowed downtime by a factor of ten. Achieving that requires redundancy across failure domains, automated failover and careful change management, which is why higher tiers are typically tied to dedicated infrastructure and enterprise agreements.
You can compute these values yourself:
def allowed_downtime(availability_pct, period_minutes):
return period_minutes * (1 - availability_pct / 100)
MONTH = 30.44 * 24 * 60
YEAR = 365 * 24 * 60
for a in (99.0, 99.5, 99.9, 99.95, 99.99, 99.999):
print(f"{a}%: {allowed_downtime(a, MONTH):.1f} min/month, "
f"{allowed_downtime(a, YEAR) / 60:.2f} h/year")
What an MQTT Broker SLA Usually Covers
Definition of Downtime
Read how "unavailable" is defined. For a broker, it might mean the endpoint does not accept new connections, that a percentage of connection attempts fail, or that messages are not delivered. Some agreements only count downtime that lasts more than a few consecutive minutes, which means short blips do not count at all.
Measurement Method
Who measures, and from where? Provider-side monitoring may see the broker as healthy while your devices on a particular network cannot reach it. Ask whether you can submit your own monitoring data when claiming credits.
Scope
Check which components are covered: connection endpoints, TLS and WebSocket listeners, the management portal, APIs used for provisioning. Portals and APIs are often covered differently from the data plane, or not at all.
Service Credits
When the target is missed, the usual remedy is a credit: a percentage of the monthly fee, often tiered by how far availability fell. Credits typically must be claimed within a deadline, and they are rarely proportional to the business impact of an outage. Think of credits as an incentive for the provider, not as insurance for you.
Common Exclusions
Almost every SLA excludes some events. Typical exclusions include:
- Scheduled maintenance announced in advance.
- Problems caused by the customer's own devices, networks or misconfiguration.
- Exceeding plan limits, such as connection or message quotas.
- Force majeure events.
- Free, trial or beta tiers.
- Issues in third-party networks between your devices and the provider.
Free tiers in particular rarely come with a contractual SLA. That is reasonable for development and pilots, but production commitments to your own customers should rest on a plan with explicit terms.
Composite Availability: Your System Is a Chain
Your end-to-end availability is not the broker's availability. A message from a sensor passes through the device, the local network, the mobile or internet provider, the broker, your backend and your database. When components are in series, availabilities multiply.
For example, if a device network is 99.5% available, the broker 99.9% and your backend 99.9%, the chain is roughly 0.995 x 0.999 x 0.999, about 99.3%. The weakest link dominates. Spending heavily on broker nines while your backend runs on a single server gains little. For architecture patterns, see MQTT broker high availability.
Designing for the Downtime an SLA Allows
Even at 99.99%, a broker will occasionally be unreachable. Build clients that tolerate it:
- Reconnect with exponential backoff and jitter, so thousands of devices do not reconnect at the same instant.
- Buffer locally on devices and gateways, then publish when the connection returns.
- Use persistent sessions with an appropriate session expiry, so QoS 1 and 2 messages for offline subscribers are queued.
- Use retained messages for state, so dashboards see the last known value right after reconnecting.
- Set a Last Will so your backend knows when a device dropped unexpectedly.
- Monitor from the outside with a synthetic client that publishes and receives a heartbeat.
The MQTT broker outage guide covers the incident side, and the MQTT production checklist turns these points into pre-launch tasks.
Availability Is Not the Same as Durability
An availability target says whether the broker accepts connections and routes messages. It says nothing about whether every message is preserved through an incident. Ask separately how sessions, queued messages and retained messages behave when a broker node restarts or fails over, and design for the answer. If a lost message would be costly, keep the source of truth on the device or in your backend and make the broker a transport, not a store. Support response times are a third, separate commitment worth reading closely.
Questions to Ask Before You Sign
| Question | Why it matters |
|---|---|
| How is availability measured, and by whom? | Determines what counts as downtime |
| What is the minimum outage duration counted? | Short outages may be excluded |
| Is scheduled maintenance excluded, and how much notice is given? | Planned downtime still affects devices |
| Which components are covered? | Portal and APIs may differ from endpoints |
| How are credits calculated and claimed? | Deadlines and caps apply |
| Is there a status page and incident history? | Shows real track record |
| What support response times apply? | Uptime and support are separate commitments |
SLAs and ConnectMQ
ConnectMQ offers several plans, from a free Serverless tier on a shared cluster to Dedicated isolated clusters, BYOC in your own cloud account managed by ConnectMQ, and Self Managed Enterprise. If your project needs contractual availability terms, discuss them with the ConnectMQ team for the Dedicated, BYOC or enterprise options, and use the questions above to review what is offered. Whatever the terms, the client-side practices in this article are what keep your fleet healthy when any broker has a bad day.
Get Started with ConnectMQ
Build and test your reconnect and buffering logic on a free Serverless broker at app.connectmq.com, no credit card required, or experiment first on the free public MQTT broker. For an overview of what a fully managed MQTT service takes off your plate, and how hosting models compare, read the cloud MQTT broker guide.
Frequently Asked Questions
How much downtime does a 99.9% SLA allow?
About 43.8 minutes per month, or roughly 8.8 hours per year.
Does an SLA guarantee my devices will stay connected?
No. It defines an availability target and the compensation if it is missed. Your devices still need reconnect logic, buffering and monitoring.
Do free MQTT broker plans include an SLA?
Free tiers usually do not include contractual SLAs. Use them for development and pilots, and choose a plan with explicit terms for production commitments.
Is 99.99% always better than 99.9%?
It allows ten times less downtime, but your end-to-end availability depends on every component in the chain. Improve the weakest link first.
