The perfect server on ServersCamp
Anyone who has run servers knows how much has to happen before even a clean one is ready: metrics, alerts, backups, restore checks, a plan for the disk that fills up at night. It is mostly routine, and all of it has to be done before the server can be trusted with anything real. We built that routine into ServersCamp. You get a fast server with the groundwork already done, and your time goes to the work only you can do.
Someone normally has to choose the tools, connect them, write the rules, test the failure cases and keep the whole thing working. We have done that part for you. Most of it is on from the start. The rest takes a checkbox in the panel. You do not need to learn a monitoring stack before your server can tell you it is running out of memory, or write a script to keep a full root disk from taking your application down.
We have also made the decisions that an empty settings page usually leaves to you. What to watch. When to warn you. When to stay quiet. What can be fixed automatically, how much it is allowed to cost, and when automation should stop and ask for help. Those defaults come from our own operating experience and established practice. You can change them, but you should not have to invent them.
People get busy. Checks get postponed, disks fill up, and a backup can go untested until the day it is needed. We built the platform to catch those ordinary gaps before they become your next outage. That protection belongs on the smallest server too, so the same tools come with every plan.
What comes with the server
- Hardware fails, your server comes back. Disks are replicated and live apart from the machine your server runs on. If that machine dies, the server starts again on another node with all its data, and you do not have to open a ticket for it.
Block storage - Backups that restore. The filesystem is frozen for a moment while the copy is taken, so it is clean. The copy is encrypted with your key, can live with another provider in another country, and can be test-booted to prove it comes back.
Snapshots and backups - Monitoring from the first boot. Charts for CPU, memory, disk, load and network start with the server. There is nothing to install.
Monitoring - Alerts with the rules already written. With your first server we load a rule set we built and tuned ourselves, so you start with alerts that work instead of an empty form.
Alert rules - A disk that grows before it fills up. When the disk gets full, it grows on its own together with the filesystem, up to the size you are ready to pay for.
Disk auto-extend - One chat for all of it. Link our Telegram bot once and it brings alerts, billing notices, new server details and replies from support into one chat. Security notices stay in your email.
Telegram bot
Inside the server we use the standard QEMU guest agent from your distribution. We publish every command we send to it, and you can switch it off from the server page at any time.
A bad night
Here is how the pieces meet on a night when something goes wrong. Your web server has a 50 GB disk, the optimized alert rules, and auto-extend set to grow by 20% up to 100 GB.
At 02:10 a log file starts growing much faster than usual. The disk passes 80% and Telegram gets one warning: which server, its IP, which mount, how full it is.
At 02:40 the disk reaches 85%. Auto-extend grows it from 50 to 60 GB, grows the partition and the filesystem inside, and checks that the server really sees the new size. The disk is now at 71%, the alert closes, and the closing message says the disk grew from 50 to 60 GB. The service never noticed. Nobody had to wake up.
At 03:00 the nightly backup runs, freezes the filesystem for an instant, and the encrypted copy leaves for another country while the log keeps growing.
If the log had kept going until the disk reached 100 GB, auto-extend would have stopped at your limit and told you so, and the disk alert would have come back. That is the one morning that needs a human, and the message tells them where to look.
Already thought through
Most of the work is in the cases nobody plans for until they happen once. A few of the ones we settled so you do not have to:
- If the disk grows but the filesystem inside does not, auto-extend stops and tells you. It does not keep buying more disk and hoping the next attempt will work.
- Growing works on a disk that is already 100% full, which is exactly when the usual resize tools fail.
- The disk never grows past the limit you set, and a trial account never past its cap.
- A server you stopped or deleted closes its alerts quietly. Turning a server off is not a recovery worth a message.
- When a burst server runs at full CPU for too long and the platform lowers its limit, you get a message saying so, and another when the limit comes back. The server does not just get slower without a reason.
- If you unlink Telegram or block the bot, alerts move to your email by themselves. Link it again and they move back.
- A backup still runs when the guest agent is off. It is taken without the freeze, the way a disk looks after a power cut, and it is not skipped.
Quiet by default
A monitoring system that people mute after a week is worse than none, so a lot of the work went into what it does not send.
The rule set we load is a preset of battle-tested checks. It is the layer we consider necessary on any server: high CPU and memory, a disk running out of space, processes killed for lack of memory, and an agent that stops answering. Together they are enough to tell a real incident from normal load, and we left out the checks that mostly produce noise.
An alert sends one message when a problem starts, one more if it gets worse, and one when it is over. A problem that returns a few minutes later continues the old alert instead of starting a new round. Every problem message has buttons to silence it for an hour or a day.
There are limits on our side too. An account gets a capped number of messages, and past the cap one note says alerts are paused and until when. If a fault of ours makes many servers look sick at the same moment, the messages are held and our own team gets paged instead of you.
Yours to change
Most of it needs no visit to settings, and all of it can be changed. Rules can target one group of servers and skip another, the auto-extend limit is yours to set, and the agent, monitoring and auto-extend each have a switch on the server page. Once you change a rule by hand it is yours, and we leave it alone.
On every plan
Monitoring, alerts, auto-extend and the bot cost nothing extra, on the cheapest server as much as the largest. Backups and the extra space of a grown disk are billed like any storage.
We do not claim to cover everything a server could need. The last part depends on what runs inside it and how your team works: only you know what "working correctly" means for your application. What we built is the rest. We took the recurring mistakes that cost people sleep, data or a working backup, and built protection against them into the platform, for every customer. It is a baseline solid enough to carry you through an ordinary day, and the one that saves you on the day something breaks.
The details are in the guides for the guest agent, monitoring and alerts, disk auto-extend and the Telegram bot.