Testing before you commit

Test the network first, from where your users are

This costs nothing and tells you more than any specification. Ask us for an address to test against, then:

mtr -rwzbc 100 <address> — from your office, from your current provider, from wherever your customers sit

Look at the path, the latency and whether loss persists to the destination. See reading a traceroute for how to read it without drawing the wrong conclusion.

Then throughput: iperf3 -c <host> -P 8 -t 30, against something well connected. See speed testing.

Test the support before you need it

Send a real technical question before you order and time the reply. Not “do you have servers available” — something specific: how is a routed /29 delivered, what happens to my data on a reinstall, which disks would you fit for a write-heavy database.

What comes back tells you whether an engineer reads your tickets or a script does. That is the thing you will actually live with, and it is the hardest to change later.

Ask for the awkward answers in writing

The nine questions in questions worth asking any provider are designed for this. The useful signal is not only the answer but how long it takes and whether it is specific.

Start small, deliberately

Take one machine for one month before you move everything. Dedicated servers here are monthly by default and paid upfront, with no minimum term beyond the month and no exit fee — see contract lengths and payment terms. That is a cheap experiment.

Put something real on it, not a benchmark: a replica of your database, a staging copy of your application, a secondary of your DNS. Real workloads find problems that synthetic tests never do.

Benchmark on day one, while it is empty

Record disk IOPS and latency, network throughput, and your own application's numbers — see benchmarking a new server. Two things come of it: you find out immediately whether the hardware is what was quoted, and you have a baseline for the argument six months later about whether anything changed.

What you cannot test in a month

How they behave during an incident, and whether the price holds at renewal. For the first, ask how a past outage was handled and whether customers got a straight account. For the second, see renewals and price changes.

And if the evaluation goes badly, leave. Leaving sets out exactly what happens to your data when you do — a provider who makes that awkward is telling you something worth hearing before you are committed.

---

Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base