You can't buy car insurance after the accident. Network support works the same way.
By Alan DeKok, CEO, InkBridge Networks
I've had a lot of conversations over 25 years with ISPs about support. One that’s still a surprise is when people tell me "We only want to pay when we call. It's cheaper that way."
I understand the logic. Why pay for something you might never use? But per incident support – some call it break-fix support - is almost never actually cheaper. What it really does is extend the duration of outages, create a tangle of payment and trust problems before a single line of troubleshooting happens, and put our support engineer in an impossible position at 2 a.m.
In order to offer better customer service, we don't accept per incident requests. This decision may seem surprising, but I’ll explain why it actually reduces risk and downtime.
What is break-fix support?
Break-fix support aka per incident support is a pay-as-you-go model: you don't pay anything until something breaks, then you pay for the time spent fixing it. For consumer software with a large, uniform customer base and predictable problems, it can work well. There are enough customers with the same small set of issues that you can train a team to follow a script. The customers are happy, the support team is happy, and everyone is pleased with the result.
For ISPs running bespoke RADIUS authentication infrastructure, per-incident support doesn't work. And the reasons start before our team has even looked at a log file.
Let’s work through your experience of calling a per-incident support line. I’ll explain what happens at every stage and show how the outcome is suboptimal for everyone.
The problem starts before we pick up the phone
Suppose your RADIUS system goes down at 2 a.m. on a Saturday. You've never worked with us before. You find our number and call.
Before any troubleshooting starts, here is what we have to sort out:
- How are you going to pay? Credit card? PayPal? A purchase order? Many companies won't approve payments without a PO, and POs typically take 30 days to process. That's not a process that works at 2 a.m.
- What about chargebacks? If you pay by credit card and the call doesn't go the way you hoped, what's to stop you from filing a chargeback? For the reasons I get into below, the success rate is low, which means that the chargeback rate for unsatisfied customers is high. That's not a compelling business model for us.
- Is there an NDA in place? Your network configuration is sensitive data. Are you comfortable sharing it without one? If you need an NDA, the lawyers aren't online at 2am, and we can’t move ahead with helping you. Sorry, we’re blocked due to legal issues!
- Can you explain what the server does? Who has access to the RADIUS servers? Is that person on the call? Can they find the log files that contain the information our support team needs?
These are the actual problems that come up, every time, with per incident requests. By the time we've sorted them out - (if that’s even possible) - your outage is significantly longer.
We don't know anything about your network
Here is something that sounds obvious but has real consequences: a support engineer who has never seen your network has to start from zero. We don’t know what your system is supposed to do. We don’t know what databases you use. We don’t know where the log files are. We don’t even know how to start or stop the server, because we don’t know what OS it’s running on!
With a support contract customer, if something goes wrong, we know what their system does, how it's designed, what database they're running, and what the common failure modes look like. We have tools already in place so that whoever is dealing with the problem at 2 a.m. - whether that's our team or theirs - doesn't have to go hunting for information in the middle of the night.
With a per incident call, the first 30 minutes (or more, realistically) is spent trying to establish those basics. What is the system supposed to do? What's going wrong? What does your network look like? Often the only answer we get is: "It's down. Users aren't authenticating."
That's not a helpful problem description. There are many different components involved in a RADIUS authentication chain, any one of which could be causing the problem. And when any one of those systems fails, the problem is “Users aren’t authenticating”.
So, everyone loves to blame the RADIUS server. In fact, it's a running joke in our industry. We've had many calls where after extensive back-and-forth, the logs finally arrive and show 1,000s of error messages which say, "The RADIUS server can't connect to the database."
That's not a problem we can fix by debugging the RADIUS server configuration. In many cases, we didn't install the database, and we don't know anything about it. We’re willing to work with the customer to resolve the outage, but the reality is that the only solution is to fix the database, not the RADIUS server.
The result of the above realizations is that per incident support is only genuinely useful for two kinds of problems: trivial ones the customer could have solved themselves, and genuinely complex ones that could take hours or days to diagnose with no prior knowledge of the system. Using per incident support for either of those problems isn’t a good outcome for anyone.
For trivial issues, people are unhappy that they’re paying for simple advice. For complex issues, people are unhappy that the solution is taking a long time. And they’re both unhappy with us.
We want happy customers, so it’s difficult for us to work in either of those two situations.
Support is insurance - and you can't get insurance after the accident
The people who ask about per incident support often frame it as a cost-efficiency question. Why pay for support if you might never need it?
Think about it the way you think about insurance. You buy insurance because something might go wrong, not because something has already gone wrong. I don't
know of any insurance company that will let you call on a moment's
notice and say: "By the way, I just had a car accident - can I get some
coverage?" It doesn't work that way.
For an ISP, the RADIUS system is critical infrastructure. When it goes down, customers can't get online. Every minute of downtime has a real cost - in customer experience, in churn risk, in potential SLA breaches.
Of course you should pay for support. The question is whether to pay for it before or after the outage. Paying after is always more expensive.
What a support contract buys you
A support agreement with InkBridge Networks starts with a configuration review. This is where a substantial part of the value is created.
We read your configuration (with sensitive data redacted), look for good and bad patterns, and make recommendations based on current best practices. The comments are often minor. But by the time we're done, we understand what your system does and how it's supposed to behave.
That knowledge is what makes us useful when something goes wrong at 2 a.m. We're not starting from zero. We know your system. We've documented the common failure modes and, for systems we've installed ourselves, we've put scripts in place so the person handling the incident - even if it's someone junior on a weekend shift - has a clear path to follow.
The practical effect is that many of the most common problems - a full disk, a database that's not responding - get resolved without us even being called. And when we are called, it's usually for something we can fix: a change in NAS behaviour after an upgrade, a configuration edge case, a genuine RADIUS issue.
For more on the importance of ongoing network maintenance rather than a "set it and forget it" approach, see our post on keeping your RADIUS system healthy over time.
Why we refuse per incident requests
So, for all of the above reasons, we can't accept per incident support requests. The outcomes are consistently poor for everyone: the customer is unhappy, the problem often isn't resolved, and we don't get paid.
On the pricing side, the numbers simply don't work. Let’s say a “generous” per incident offer from an ISP is $1,000. That ISP has 10 million users. The $1,000 figure might be what a large IT department spends on coffee in a month. It doesn't come close to covering the cost of a world-leading expert reading hundreds of pages of unfamiliar documentation at 2 a.m., sorting out payment logistics, and solving the problem.
On the low end, we've had requests from people willing to pay $100 per incident. Unfortunately, our standard engineering rates are higher than that. There's no model in which per incident support makes financial sense for either party.
If we were going to offer it, the economics would require charging several thousand dollars upfront - in cleared funds, not PayPal - before we even begin. At that point, you've essentially paid for a support contract without any of the ongoing benefits.
Break-fix vs. managed services: a summary
The bottom line
Per incident support sounds like a way to save money. In practice, it delays resolution, creates logistical problems before troubleshooting even begins, and puts an unfamiliar engineer in an impossible position when your network is down and your customers are offline.
If you're running critical network authentication infrastructure - particularly as an ISP - you need a support relationship that's in place before something goes wrong. Learn more about our maintenance and support services and support packages, or get in touch to discuss your requirements.
Related Articles
Don’t "set it and forget it"
So you decided that whatever you were using for network security wasn’t getting the job done… either it didn’t scale with the growth in your user base, devices, or network design, or it was hindering your organization’s productivity. Or maybe you suffered a security breach. Whatever the case, you decided to make the jump to RADIUS authentication, and you’ve implemented a RADIUS server.
FreeRADIUS - Maintenance & Support
FreeRADIUS maintenance and support from the experts behind the code. Get help with troubleshooting, configuration reviews, performance tuning, security updates, and complex deployments, backed by deep protocol expertise and enterprise-grade support when uptime and reliability matter most.