⚙️ So what does SLA really mean?

I got an email the other day from a hosting provider bragging about “five-nines uptime.” Looked impressive, until the fine print (page six, tiny font) carved out nightly maintenance, regional outages, and—my favorite—“events beyond reasonable control.” In other words: the guarantee disappears exactly when you need it most. That’s the reality of an SLA—Service Level Agreement—and it pays to treat the headline number as a teaser, not a promise.

The formal definition is simple enough: an SLA spells out how fast the vendor reacts, how stable the system stays, and what happens if they slip. The tricky part is everything hidden between the commas. I’ve been drafting these documents for a few years now, and every time I think I’ve covered all angles, another edge case pops up (I could be wrong, but I suspect lawyers have a subscription service for inventing new exceptions).

Still, clients want a concrete list, so at mindnow we bundle three main guarantees. They look standard on paper, yet the devil—that cliché is true—lives in the footnotes.

⚡ Uptime guarantees – We commit to 99.9% availability. That translates to about 9 hours of allowed downtime per year, not “about nine” as marketing decks like to round it. Add just one more nine (99.99%) and you drop to somewhere around an hour. The cost curve is anything but linear. Also check the exclusions: planned maintenance and force-majeure often sit outside the calculation, quietly inflating the real outage window.

🤗 Support guarantees – The SLA says we respond within four business hours for non-critical issues. Notice the phrase “business hours.” One client skimmed past that, opened a ticket at midnight, and felt rightly annoyed when nobody picked up until morning. We now highlight the line in neon yellow (figuratively) and walk new customers through it in person—prevention is cheaper than apology.

🔧 Bug-fixing guarantees – Depending on severity, the clock starts at 8, 48, or 120 hours. But sometimes the fastest path to compliance is not a heroic midnight patch but a rollback to the last stable build. Paying the small overhead of a controlled fallback can beat the big bill of firefighting in production. I learned that the hard way after chasing a memory leak for two days while the previous release sat there, perfectly healthy, begging to be redeployed.

The SLA exists because software behaves like a toddler: fine one moment, sticky fingers in the power socket the next. A few common culprits:

🔐 Security holes – New exploits show up weekly. Log4Shell had us patching servers at 2 a.m. last December; I doubt it will be the last time.

🐞 Unforeseen usage patterns – Users are creative. Someone will eventually do the thing you never considered and the app will throw a tantrum.

📦 Dependency drift – Pin all the versions you like; sooner or later an indirect package updates, breaks ABI, and your CI/CD pipeline turns red. Been there more times than I’d like to admit.

Plenty more could go wrong, but you get the idea.

If you’re about to ship a product, think beyond launch day. Either budget for ongoing development or move into a maintenance mode with a written SLA. And—this part often gets overlooked—define the communication protocol: who declares an incident, who sends status updates, and how both sides sign off once it’s resolved. Otherwise you end up in a “you never told us” loop while the downtime counter keeps ticking.

Bring the SLA discussion forward—weeks before go-live, not the morning after the first outage. 🥲

Other Newsletter Issues:

🥇 The unfair advantage
🎃 We’ll add it to the backlog
💀 Every app has its skeletons