Dedicated hosting management: start with what downtime costs you
It is Monday morning and the ordering application does not respond. Or it is the first day of a campaign and the webshop slows down with every visitor. Or the link with the ERP system froze overnight and nobody notices until orders go missing. You call the hosting provider, who points to the developer, who asks whether someone in-house changed something. Mornings like that show whether the dedicated hosting management in your business is in order.
A server of your own gives you predictable capacity and control over the configuration. That alone does not make it well managed. Hardware, operating system, updates, backups, monitoring and the application itself have to fit together, and someone has to own that whole. Below you will find what to arrange first, what can wait and where the trade-offs are.
Work out what downtime costs first
Start with the business impact. The amount of RAM and the number of processor cores come later. An internal time-tracking system that is down for a morning is annoying. An ordering platform where revenue comes in every minute is a different story. Data loss works the same way: for one organisation a day of data is manageable, for another a few hours is already too much.
For each application, write a short overview: which processes depend on it, when the peaks happen and how much downtime you can live with. Include the integrations. An application can run perfectly well and still get stuck because the database, the payment provider, the stock integration or the mail server does not answer.
That overview protects you from two expensive mistakes. The first is a server that runs fine on quiet days and collapses as soon as a campaign, import or traffic spike starts. The second is the reverse: buying heavy infrastructure for a problem that a smarter configuration or a faster application would have solved.
Then put the agreements in writing. How quickly is an incident picked up, which systems take priority, when may maintenance take place and who can make decisions for you outside office hours? As long as those answers are missing, ‘24/7 management’ is a promise you cannot do much with.
Monitor what your users see
In many businesses an employee or customer is the first to notice that something is wrong. By then you are too late. Monitoring that only checks whether the server is online misses the signals that announce a problem: memory use that keeps climbing, a disk filling up, rising response times, a failed backup or a database that demands more and more capacity.
A server can be perfectly reachable while your application is unusable for its users. So measure the whole chain. Does the page load? Does the most important API respond? Did the background job that should have run last night actually run?
Then comes the follow-up, and that is where things stall more often than in the technology. A warning sitting unread in a mailbox solves nothing. Agree on who analyses, who intervenes and when you are informed. A quick phone call from someone who knows what is going on is worth more than an automated ticket without context.
A check for today: open the folder or channel where your monitoring alerts arrive and count how many of them nobody picked up in recent weeks.
Patch holes now, schedule the rest
On a server running in production there is always an update waiting. Postponing it creates risk. So does pushing everything through blindly, because an update can clash with custom code, an outdated library or a specific integration.
So use a fixed split. Critical security updates go first and are applied as soon as possible. Regular updates are tested first and scheduled for a quiet moment. If a business-critical environment runs on the server, set up a test or acceptance environment, so a change is never tried out for the first time under live load. That extra environment costs money and upkeep. For a closed internal tool you can skip it. On an ordering platform it pays for itself with the first update that would otherwise have gone wrong live.
Patching is half of security. Give access only to people who really need it, use strong authentication and clear user rights, set firewall rules and keep logs. A public application with personal data needs more than a closed internal tool, but that baseline belongs on every server.
A backup counts only after a restore test
‘We make a backup every night’ sounds reassuring. As long as nobody has tried to restore it, all you know is that something is being written somewhere. A backup can be incomplete, become encrypted, sit on the same infrastructure as the original or no longer match the current version of your application.
For each system, decide what is backed up, how often and how quickly a restore must be possible. For many systems a nightly copy is enough. On a platform with continuous transactions, losing a few hours can already be too much, and then you need more frequent snapshots, separate database backups and storage at another location.
Also record who carries out the restore and how you check afterwards that everything works. Restoring the database is step one. After that, orders, user rights, integrations and background processes have to work again, and checking that takes at least as much attention.
If you do one thing this week, pick one backup and restore it to a separate environment. Then you know whether your recovery plan works.
A bigger server is rarely the first step
A dedicated server has a ceiling too. Capacity management is about seeing growth coming before users notice it: more traffic, a growing database, more users or a new feature that computes more heavily than expected.
Look at the peaks, because averages almost always look reassuring. A publisher gets a spike with big news, a webshop with a promotion, an agency with the launch of a client campaign. Watch scheduled processes as well. Reports, imports and indexing jobs can put a heavy load on a server at the worst possible moment.
When the server gets tight, look at caching, database optimisation, more efficient code and spreading heavy jobs first. That often achieves more than extra hardware. If you still need more capacity after that, you carry out the upgrade in a controlled way, at a moment you choose yourself.
Dedicated hosting management belongs with one team
Most of the time is won through clear responsibility. If the party that knows your application also manages the server, it is quicker to see where a slowdown comes from: the code, the database, the infrastructure or an external API. Your team no longer has to act as the go-between for suppliers.
For businesses with custom software or complex integrations this matters most, because development and hosting affect each other. A new feature can push up the server load. A change to the infrastructure can affect an integration. When that knowledge sits with one team, changes are better prepared and incidents are solved faster. The flip side is that you become more dependent on that one party. So ask about documentation and about access to your own environment.
LJPc combines custom development with dedicated hosting and technical management, so one team looks at the whole chain. You get short lines and clear responsibility, and your own people keep their time for customers and growth.
Four questions for your next hosting conversation
Comparing prices and server specifications is the easy part of a conversation with a management partner. These questions tell you more:
- How is monitoring set up, which alerts are actively followed up and what are the normal response times?
- How are updates scheduled, where are the backups stored and how often is a restore tested?
- How are you informed during an incident, and does that update tell you the impact, the action under way and when the next update follows? A message saying someone is ‘looking into it’ is not enough.
- What happens when your platform doubles in users, processes more data or gets new integrations?
Ask them of your current provider first. If the question about restore tests gets no concrete answer, schedule a restore test together before you discuss anything else. And if you want to hear how we answer these questions in Assen, put them to LJPc.