Dedicated Server Contract Checklist: 11 Spec Fields to Verify (with Benchmarks)

A dedicated server contract runs 12 to 36 months, and nearly every cancellation dispute traces back to one of eleven spec-sheet fields the buyer never verified before signing. Below is each field, why it changes your annual cost, and the exact number or document to request. Total time to run the checklist against a shortlisted provider: about 25 minutes.

1. The exact CPU SKU, plus a per-core benchmark result

“Intel Xeon, 16 cores” is a product class, not a spec. Ask for the full SKU (e.g. Xeon Gold 6248R, EPYC 9354P, Ryzen 9 7950X) and check its single-thread result against a modern baseline. Published PassMark single-thread figures illustrate the spread: a 2014-era Xeon E5-2699 v3 scores roughly 1,790, a Xeon Gold 6248R roughly 2,500, and a Ryzen 9 7950X roughly 4,600. A 3x difference in single-thread throughput is the difference between 40 and 110 Minecraft players on the same core count, because the main tick thread is serial. Ask the provider to confirm the SKU in writing, not “Xeon or equivalent.”

2. Sustained all-core boost clock, not the marketing boost

Vendor boost numbers assume one active core and generous power headroom. In a 1U chassis with 12–16 DIMMs, sustained boost typically lands 300–700 MHz below the sticker. Request the clock under a sustained all-core load, or run a 10-minute stress-ng --cpu test yourself during the trial window and read grep MHz /proc/cpuinfo every 30 seconds. If the node cannot hold its base clock, every game instance on it loses headroom during player peaks.

3. Core-to-thread layout, and whether SMT is on

A “32 vCPU” allocation can mean 16 physical cores with SMT, or 32 cores across two NUMA nodes. For a single game instance this rarely matters; for a fleet of 8–24 instances it does, because the scheduler will move threads across NUMA boundaries under load. Ask whether the provider exposes a topology map and whether you can pin cores. Servers without pinning control typically deliver 5–12% worse tick stability at high instance density.

4. RAM generation, channel population, and ECC

DDR4-3200 versus DDR5-4800 changes real throughput by 15–30% on memory-bound workloads (large modpacks, Rust entity lists, Valheim terrain streaming). More important: ask how many channels are populated. A 128 GB allocation delivered as 4×32 GB in a 8-channel platform runs at half the memory bandwidth of 8×16 GB. Also confirm ECC — unbuffered non-ECC RAM can silently corrupt long-running world saves, and the provider’s standard rebuild does not recover a corrupted region file.

5. Storage model: drive count, RAID, and steady-state write speed

“NVMe SSD” says nothing about redundancy. A single 1 TB NVMe is a single point of failure with a rebuild time of zero. Ask for the exact drive model, count, and RAID level (RAID 1 for OS, RAID 10 for world data is the minimum sane configuration), then verify steady-state write throughput after the SLC cache drains — look for published figures around 1.5–3 GB/s sustained on enterprise NVMe versus 200–400 MB/s on QLC drives that run out of cache. This is the number that decides whether a 5 GB world save finishes in 3 seconds or 20.

6. Bandwidth billing method: 95th percentile, commit, or unmetered

Three plans with the same 1 Gbps port can cost $89, $159, and $349 depending on transfer policy. Metered plans bill per TB overage; 95th-percentile plans bill the 95th-percentile five-minute sample, which absorbs 72 minutes of spike per month; unmetered plans carry fair-use clauses that are rarely in the contract. Ask for the billing method, the inclusion amount, the overage rate per TB, and — for 95th percentile — whether inbound traffic is counted. See dedicated server hosting plans with clear bandwidth terms for how these are typically quoted.

7. DDoS mitigation capacity and attack-type coverage

Mitigation is measured in two units: bandwidth (Gbps) and packet rate (Mpps). A game server is easier to knock over with 8 Mpps of small UDP packets than with 40 Gbps of bulk traffic. Ask for the scrubbing capacity, the packet-rate filter ceiling, and whether UDP reflection (NTP, DNS, SSDP, CLDAP) and game-protocol floods are filtered inline. Verify the answer in writing; “1 Tbps DDoS protection” in marketing copy often refers to the transit provider’s aggregate capacity, not per-IP filtering.

8. Network port, peering, and transit mix

A 10 Gbps port is not the same as good routing. Ask for the provider’s ASN, their top three transit providers, and whether they peer at an IXP near your player base. Use a looking glass or public route-server query to check your own ISP’s path to their prefix before signing. Bad peering adds 20–40 ms and 3–8 ms of jitter that no amount of CPU upgrades will fix.

9. IP allocation: usable addresses, rDNS, and justification rules

Most plans include one IPv4. Multi-instance game hosting and proxy networks need 4–32 addresses, and ARIN/RIPE justification rules mean you cannot always buy them later. Confirm the price per additional /29, whether rDNS is self-service, and whether IPv6 is a /64 or /48 by default. A missing /64 blocks dual-stack rollout and forces CG-NAT workarounds for IPv6-only players.

10. Uptime SLA wording and the compensation mechanism

99.9% monthly uptime allows 43 minutes of downtime. Read the definition: does it include scheduled maintenance? Does it measure ping, HTTP, or power state? And what does the credit actually pay — typically 5% of monthly fee per 0.1% below target, capped at 100%, and only if you open a ticket within a stated window. An SLA without a self-service incident log is difficult to claim against.

11. Hardware replacement time, remote hands, and IPMI access

Ask three questions: what is the guaranteed replacement window for a failed drive or DIMM (4 hours and 24 hours are different products), is remote hands included or billed hourly, and do you get full out-of-band console access (IPMI, iDRAC, iLO) with virtual media? Without out-of-band access, an unbootable kernel means a ticket and a multi-hour wait instead of a five-minute fix.

Verified-spec scorecard: what to send before signing

Field	Acceptable answer	Red flag
CPU	Full SKU + single-thread score	“Xeon or equivalent”
Boost clock	Sustained all-core figure	Sticker boost only
RAM	Generation, channel count, ECC	Capacity only
Storage	Model, count, RAID level, sustained write	“SSD included”
Bandwidth	Billing method + overage rate	“Unmetered”
DDoS	Gbps and Mpps figures, attack types	Aggregate network capacity
Uptime	Definition, exclusions, credit table	Headline percentage only
Access	IPMI/iDRAC/iLO with virtual media	Ticket-only console

Run the checklist in this order

Send the eight table fields as a single email and ask for written answers. Compare the replies side by side; the provider that answers in specifics rather than adjectives is almost always the one that also holds up operationally. Then, once the server is provisioned, spend the first 30 minutes verifying what you were sold — CPU SKU via lscpu, drive model via nvme list, channel population via dmidecode -t memory, and sustained boost under load. If any field disagrees with the quote, you have a documented basis for remediation or cancellation inside the trial window rather than a year of silent underperformance.

The one line that matters

You are not buying cores and gigabytes; you are buying a specific set of sustained, verifiable numbers. Ask for them before you sign, and confirm them after deployment — that two-step process eliminates the majority of dedicated hosting regret.