Dedicated server pay as you go: a whole machine, billed by the hour

What can be ordered by the hour

Hourly billing applies to any dedicated server that is racked and ready, ordered exactly as it stands. Those are the machines listed on instant dedicated servers: already in a rack, live about 30 minutes after the order is approved. The hourly rate is printed beside the monthly price there, on the dedicated range and on the order page.

The rule follows from the hardware. An hourly machine is one that already exists in the rack; anything we have to assemble for you, such as a GPU fitted to order, is a build and is sold by the month.

The billing cycle, step by step

1. Order. Pick a ready server and choose hourly. The rate is the server's monthly price / 730 x 1.3, and it is fixed at the order.
2. Card. A card is saved and a hold of one week at the hourly rate is placed on it. The hold is not a charge; it is released after the first usage invoice is paid, or when the account closes.
3. Delivery. The meter starts when the server is delivered, not when you click order, so the time it spends being prepared is not billed.
4. Running. Usage accrues by the second and is invoiced to the cent. A server released within its first hour pays one hour.
5. Invoices. Usage is invoiced in arrears on the 1st of each month, or sooner when unbilled usage crosses a threshold that starts low and doubles with each paid usage invoice, up to a fixed ceiling. Each invoice is charged to the card on file.
6. Release. Releasing from the dashboard is immediate: the unbilled hours go on a final invoice charged at once, and the server is gone.

An unpaid usage invoice suspends the server after 24 hours and releases it after 7 days. A released server is not kept for you: copy results off before you release it.

Where the monthly price wins

A server needed for most of the month is cheaper on the monthly price. The arithmetic below is ours, from the published formula: 730 hours is the average month, and the 1.3 factor makes each hour cost 30% more than a 730th of the monthly price.

If a job will keep a machine busy for more than about 23 days of the month, order it monthly. If you cannot tell yet, start hourly: you pay only for the hours you run. If the job turns out to need most of the month, order a monthly server for it, copy your data across, and release the hourly one.

Jobs that fit hourly bare metal

• Benchmarks. Single tenant, no hypervisor, and an access-switch port no other customer shares, so the numbers describe the machine and not a neighbour.
• One render or batch run. Every core and all the memory for the length of the job, then release.
• Load tests. A load generator needs CPU headroom and a clean uplink; the port is unmetered, so the traffic a test pushes is never billed. Sizing and OS tuning are on the k6 load testing server page.
• CI bursts. A release week of builds on a whole machine instead of a queue; runner setup is on the self-hosted runner page.
• Trying a line. Run your own workload on the exact processor, memory and disks you are considering, then order the same class monthly if it holds up.

A benchmark session from delivery to release

1. Confirm the hardware you were delivered: processor model and core count, memory, block devices.
2. Install fio from the distribution's repository (Ubuntu carries it in universe).
3. Run the disk test against a file, not a raw device: a write test aimed at a device destroys what is on it.
4. Copy the JSON results to your own machine.
5. Release the server from the dashboard. The final invoice covers the hours not yet billed.

# on the server
lscpu; free -h; lsblk -d
sudo apt install fio
fio --name=randread --filename=/root/fio.test --size=4g \
    --rw=randread --bs=4k --ioengine=libaio --iodepth=32 --direct=1 \
    --runtime=60 --time_based --group_reporting \
    --output-format=json --output=/root/fio-randread.json

# from your own machine, before releasing
scp root@SERVER_IP:/root/fio-randread.json ./

--direct=1 bypasses the page cache, so the run measures the disk and not memory; fio's documentation notes that libaio may only queue asynchronously with non-buffered I/O. --time_based keeps the job looping for the full --runtime even after the file has been read once. For repeat runs on a clean system, the instant line offers OS reloads from the panel without opening a ticket.

Hourly bare metal or a per-second VPS

For short jobs that would leave most of a server idle, the Elastic Cloud VPS bills compute per second while it runs; the hourly VPS page sets out what it charges in each state. Pick between them on what the job measures.

Limits of hourly billing

• A new account can run two hourly servers at once; more come with paid history.
• An hourly order takes the machine exactly as it stands; a different configuration is a monthly build: see the custom builder.
• There is no minimum term and no contract, but there is also no discount: prepaid terms, which take money off the machine, are monthly only.
• Release is final. The server and everything on its disks are gone once you release it.