How much a system stays up, expressed as a percentage, and the formal promise (SLA) to keep it above a level.
Why it exists
Customers and partners need to know how reliable a service will be, and a vague promise is not enough to plan around. Uptime and SLAs exist to state reliability as a measured number and a commitment, so expectations and consequences are explicit.
How it actually works
Uptime is the share of time a service is working. It's quoted in nines: 99.9% sounds perfect but allows about 8.7 hours of downtime a year; 99.99% allows under an hour. Each extra nine is dramatically harder and costlier.
An SLA (service level agreement) is a contract promising a level, with consequences (like refunds) if you miss it. Vendors give you SLAs; you may give them to your customers.
A senior PM walks you through it
A junior PM, stuck
A corporate client's procurement team asked what uptime TiffinBox commits to, and whether 99.9 versus 99.99 percent actually matters. I have been quoting 99.9 in the sales deck because it sounds safe, but I cannot explain what it really promises or whether we can even go higher. I do not want to commit us to a number in a contract that we cannot actually hit.
The gap between 99.9 and 99.99 is not marketing gloss, each nine is a specific budget of allowed downtime minutes, and there is a small table that converts one to the other. Reading it, and checking it against what you actually depend on, takes about five minutes. This is the SMS vendor's SLA page next to your own last month, which is everything you need to answer procurement. Read it top to bottom, then take the steps with me.
SMS vendor SLA, next to TiffinBox last month
Vendor SLA
Commitment: 99.9% uptime, measured per calendar month.
Service credits: under 99.9% gives 10% back, under 99.0% gives 25%, under 95.0% gives 50%.
Scheduled maintenance windows are excluded from the measurement.
Nines to downtime, per month
99% about 7 hours 18 minutes of allowed downtime
99.9% about 43 minutes
99.99% about 4 minutes
TiffinBox status page, last month
Recorded downtime: 43 minutes total.
Largest event: Friday 2026-03-06 checkout 500s, 13:04 to 13:19, 15 minutes.
Computed uptime: 99.90%.
Click a step to see the lines it points at.
Mistakes I've seen
Quoting an uptime number in a contract without checking what you depend on. Your SMS vendor promises 99.9%, so promising a client 99.99% signs you up for a gap you cannot close on your own.
Treating 99.9 and 99.99 as basically the same. Per month they are 43 minutes versus about 4, a real 39-minute difference and a large jump in cost and effort to hold.
Reading uptime as a vibe instead of a minutes budget. "Very reliable" cannot be planned around; "43 minutes a month allowed, 43 used" can, and it is what a procurement team is actually asking for.
Forgetting the penalty half of the SLA. A commitment with no service credits gives the client nothing when you miss, and the credit tiers are exactly what they are scrutinizing, so read them before you promise the number.
Tell procurement: "We commit to 99.9% monthly, which is about 43 minutes of allowed downtime, and last month we came in right at that. We cannot commit to 99.99% because our SMS provider only guarantees us 99.9, and we will not promise more than our dependencies do." You just answered an SLA question in minutes and dependencies instead of a comfortable-sounding percentage, which holds up in any contract conversation.
Where a PM meets this
"How much downtime is acceptable?" is a product and cost decision; chasing more nines gets expensive fast.
When choosing a vendor, their SLA is a real comparison point; when selling to businesses, yours becomes a negotiation.
Hear it in a meeting
"Their SLA is 99.9%, so we can't promise our customers more than that."