Darren Sandford, VP Infrastructure and Support
White Label Communications
Your brand is on the line every time a customer picks up the phone. And when service is down, they don’t care whose component failed — they just know it’s down.
On paper, 99.9999% availability translates to only a few seconds of downtime per year. In practice, that level of uptime changes how a business operates: issues surface less often, escalations drop, and customers stop thinking about the infrastructure behind their service.
The math is easy to understand. The work behind it isn’t.
Six nines isn’t a claim. It’s a track record, earned quietly, year after year.
Here’s what it takes in the real world:
Six Nines Is the Result, Not the Plan
Nobody wakes up and “chooses” six nines. You get there the hard way: you find a weakness, remove it, assume there’s another hiding, repeat.
Assume something will fail, then design so it can, without taking customers down. Fix one weak point, and you go looking for the next.
Reliability starts with eliminating points of failure. It continues with layered redundancy, geographic distribution, and constant review of vendor dependencies. You never assume upstream providers are truly independent. You verify. Then you verify again. We map dependencies, test failover paths, and revisit those maps regularly. Because the thing that was “independent” on paper two years ago may not be independent after the next acquisition or routing change.
We’re also careful what we share publicly — details can become a roadmap.
And you keep asking yourself and your trusted experts a simple question: What have we missed? What assumption are we making that no longer holds?
Those questions never go away. If they stop being asked, uptime starts slipping.
The Engineering Discipline Behind It
Design for Loss, Not Convenience
A lot of environments drift toward convenience over time. We try to anchor on loss scenarios first, and let convenience be the byproduct.
We plan for a facility going offline. We plan for hardware failure. We plan for a provider experiencing regional issues. We design systems to fail over automatically, without manual intervention.
Geographic and logical diversity both matter. Multiple systems mean little if they share the same dependencies.
If it can’t fail cleanly, it isn’t finished.
Change Management: No Surprises
Architecture gets the attention. Change management protects it.
Every change is reviewed, tested, and paired with a rollback plan.
For changes, we aim for two outcomes: it works as planned, or we roll it back cleanly with no customer impact. The messy middle is where incidents are born.
Six nines doesn’t survive casual change. Most avoidable outages start as “small” changes.
Good change management is built on experience, not reaction.
Monitoring is easy to add. It’s harder to operationalize.
Alerts without response capacity create noise. Noise creates fatigue. Fatigue creates risk.
As your systems scale, monitoring must scale with them. Automation handles obvious patterns. Experienced engineers handle the judgment calls. There isn’t one perfect checklist for this, but there are hard rules. A simple rule: every new alert needs an owner, an action, and an SLA. If you can’t name those, it’s noise.
You’ve got to scale your team ahead of growth. You invest in monitoring improvements before the cracks show.
Continuous improvement becomes routine. Every incident, near miss, and change becomes an opportunity to refine the system.
Six nines is maintained through iteration.
The Culture Required
Reliability comes from people, not diagrams.
Seasoned engineers who understand complexity and resist shortcuts drive success in uptime. Six nines depends on mature decisions made under pressure. Under pressure, maturity looks like doing the boring thing: follow the process, don’t wing it.
You have to care enough to assume something will go wrong. You have to look at a stable system and still ask where it might break. You have to revisit decisions that were correct five years ago and ask if they still are.
This level of uptime isn’t the result of heroics. It comes from years of steady refinement through long nights and hard conversations about tradeoffs.
The day you think you have arrived at “good enough” is the day reliability starts slipping.
Complacency is the real enemy of uptime.
The Reality: There Is a Balance
There’s another truth that often goes unspoken: it’s possible to engineer yourself into bankruptcy.
Infrastructure is a cost center. The return isn’t always visible until something breaks. Every dollar spent on redundancy, monitoring, or capacity has to make sense. You can’t eliminate every conceivable risk. You can only reduce it intelligently.
We treat every investment as if it were coming out of our own paycheck. Does it remove meaningful risk? Does it support future growth? Does it strengthen the foundation?
Reliability has to be sustainable.
Why This Matters to RSPs
For the resellers and service providers we support, uptime isn’t a technical metric. It’s reputational. And reputations affect revenue. And as you scale, the ticket volume — and the cost of every incident — compounds.
Outages turn into reputational debt fast: fire drills, escalations, and uncomfortable conversations with customers who expected better.
Higher availability means fewer tickets, fewer apology calls, and fewer upset customers. It means you can sell into larger accounts with confidence because you trust the foundation behind you.
Reliability gives you room to grow. It doesn’t show up on a spec sheet.
When your infrastructure partner takes uptime seriously, you can focus on growing your business instead of defending it.
Six Nines Is a Responsibility
Six nines is an achievement, but not a trophy.
It requires constant review, continuous improvement, disciplined change, thoughtful investment, and humility.
You can only earn 99.9999% when you assume a layer will fail and design it so that the whole system doesn’t fail with it.
The conversation isn’t about percentages. It’s about responsibility.
The only way to keep six nines is to keep asking how it can be better.
If you’re evaluating an infrastructure partner, ask them one question: “Show me the last three incidents; what failed, what you changed, and how you proved it won’t repeat.” If you want, we can walk through what ‘good’ looks like.