Hourly vs monthly VPS billing: the break-even point and 10 ways to cut your bill

An hourly server is cheaper only when your machine isn't really running all month — and "really" means a number you can calculate, not a feeling you can argue about. This guide to hourly vs monthly VPS billing builds the break-even formula, compares six usage patterns with real numbers, and gives you ten measured ways to cut the bill.

Hourly vs monthly VPS billing: why "monthly price ÷ 730" isn't the answer

With an hourly server, the billing unit changes from the month to the hour: instead of a fixed amount at the start of each period, the cost of every hour the machine is running is deducted from your prepaid wallet. The standard month in this calculation is 730 hours, but the real difference isn't in dividing one number by another; it's in your right to stop.

If the basic concept and the wallet mechanism are new to you, start with our introduction to hourly cloud servers; this article is about the numbers.

Three differences you won't see in a price list

• Granularity. On a monthly plan, the smallest unit you can buy is a month; on hourly billing it's an hour. A wrong decision costs you one hour instead of 730.
• Commitment discount. Monthly rent is usually cheaper than the hourly rate multiplied by 730, because you get a discount in exchange for committing. That discount pulls the break-even point below 730 hours.
• "Off" versus "deleted". On a monthly plan, powering a server off saves nothing. On hourly billing it saves something, but not everything: as long as the server exists, its resources stay reserved and a percentage of the rate is still charged.

In one sentence: an hourly server is a tool for managing uncertainty. Wherever you don't know how long you'll need the machine, pay-as-you-go is cheaper; wherever you're sure it will run for months, a long-term commitment is.

The hourly server break-even formula: after how many hours does monthly win?

The break-even point is the number of hours at which the hourly model costs exactly as much as the monthly rent. The answer depends on one condition: during idle hours, do you delete the server, or just power it off? If you delete it, the point is M ÷ H. If you only power it off, the server still bills a percentage of the full rate, and the line moves lower.

Take H from the pricing calculator on our homepage; prices change, and that's where the current figures live. M is the price of the same configuration at the monthly-rental service you want to compare against — Mehran Host itself has no monthly contracts, so M is an outside input to your comparison. The off-state percentage for a powered-off server is set out in our terms of service.

# M = monthly price of a spec, H = its full hourly rate
# k = share of H still charged while the VM is powered OFF (0 = free, 0.5 = half)
#
# case A - server is DELETED during idle hours:
#     N* = M / H
# case B - server is only POWERED OFF (it keeps existing):
#     H*n + k*H*(730-n) = M   ->   N* = (M/H - 730*k) / (1 - k)

# unitless ratio only - no currency, no real tariff:
R=500        # = M / H
K=0.5        # off-state share of the full rate
awk -v r=$R -v k=$K 'BEGIN{
  b=(r-730*k)/(1-k);
  printf "delete-when-idle: %.0f h/month (%.1f h/day)\n", r, r/30.4;
  printf "power-off-only  : %.0f h/month (%.1f h/day)\n", b, b/30.4;
}'
# delete-when-idle: 500 h/month (16.4 h/day)
# power-off-only  : 270 h/month (8.9 h/day)

The gap between those two lines is the whole story. If you only power the machine off, the monthly plan has already won before you reach nine hours of work a day; but if you take a backup and delete the server, the hourly model stays cheaper up to about sixteen hours a day.

One subtlety: as long as the server exists, all of its resources — RAM, CPU, disk and IP address — stay reserved on the host hardware. That's why powering off doesn't bring the hourly rate to zero; it cuts it to a percentage. So the hourly cost line doesn't start at zero: it has a real intercept.

Don't guess your real running hours — read them

Bad estimates come from believing the server is on "only a few hours" when it hasn't been powered off for weeks. There are two places to read the truth: the itemized list under Transactions in the panel, and the kernel's own counter:

uptime -s
# 2026-07-21 09:12:44   -> exact boot time

awk '{printf "uptime: %.1f h\n", $1/3600}' /proc/uptime
# uptime: 484.2 h        -> hours since the last power-on

An important caveat: both numbers count only from the last power-on and reset on every reboot, yet a reboot doesn't pause the full-rate charge — only powering off does. So this number is a floor for the hours you've been charged; see the complete list with last -x reboot shutdown.

Which usage patterns suit an hourly billed VPS? Six real scenarios

The hourly model pays off when the machine's running hours stay below the break-even point. The table below compares six common patterns, assuming you delete the server during idle periods and a break-even point of 500 hours a month. If you only power off instead of deleting, the line drops to about 270 hours, and the seasonal-campaign row sits right on it.

There's a seventh pattern that doesn't fit in the table, because its running hours aren't known in advance: a relay server brought up to try out several network routes, which is either deleted or made permanent once a route has been chosen. We cover how to choose and set one up in our guide to choosing a tunnel server. For now, just note that during the trial period, hourly billing is the only model that lets you try three routes without paying a full month for two of them.

How to read the break-even chart

The monthly cost is a horizontal line; the hourly cost is a sloping one. Where they cross is the break-even point: to the left is hourly territory, to the right is monthly territory.

What makes up an hourly server bill?

An hourly cloud server bill is made of five parts: CPU, memory, disk, IP address and traffic. The key point is that powering off removes none of the first four — their resources stay reserved — it only cuts the hourly rate to a percentage of the full rate. Traffic is the only part that isn't tied to time.

• CPU. Charged for the cores allocated to you, not for how busy they are. An idle server costs as much as a busy one; the way to cut this part is to downsize, not to do less work.
• Memory (RAM). As with the CPU, the allocated amount is what counts. RAM that never fills up is pure cost.
• NVMe disk. The space is occupied on the host hardware whether the server is on or off, and it's freed only when the server is deleted.
• Public IP address. A scarce, reserved resource. An additional IP is usually charged at the full rate whether the machine is on or off.
• Traffic. Tied to the gigabytes transferred, not to time. A server can run for 24 hours and use almost nothing, or move hundreds of gigabytes in two.

A one-time test: deliberately leave the server powered off for an hour, then look at that hour's charge in the panel's transactions. Divide it by the charge for an hour of running and you have the k to put into the formula.

Ten measured ways to reduce cloud server costs (in order of impact)

On hourly billing, money leaks from three places: a machine bigger than you need, hours it stayed on for no reason, and resources nobody went back to once the work was done. The ten methods below are ordered from the biggest impact to the smallest; the first four deliver most of the savings.

1) Right-size based on actual usage

Most servers are built one size larger than they need to be, because on day one nobody knows the real usage. The trouble is that htop and free -m show only the current second, and they never answer "what was this week's peak?" To right-size you need history. A week from now you'll have it, as long as you enable sysstat on day one:

# Debian / Ubuntu
sudo apt install sysstat -y
sudo sed -i 's/^ENABLED=.*/ENABLED="true"/' /etc/default/sysstat
sudo systemctl enable --now sysstat

# AlmaLinux / Rocky
sudo dnf install -y sysstat
sudo systemctl enable --now sysstat sysstat-collect.timer sysstat-summary.timer

sar -r          # memory history for today
sar -u          # CPU history for today
# history files: /var/log/sysstat/ on Debian, /var/log/sa/ on RHEL family

Collection starts the moment it's installed, so until the collector writes its first sample (every 10 minutes by default), sar answers with "Cannot open …". The decision rule: if peak RAM use over a week stays below 50 percent and average CPU below 20 percent, rebuild one size smaller. Go by the peak, not the average — sizing by the average leads you straight to the OOM killer.

2) Scheduled server shutdown with cron

A test environment or a training machine has no reason to stay on around the clock. One cron line takes the month from 730 hours down to about 200. The line below assumes Iran's Saturday-to-Wednesday working week, so it skips Thursday and Friday; change the day list to fit your own week:

# root crontab — power off at 18:00, Iranian work week (Sat–Wed)
# cron day-of-week: 0=Sun 1=Mon 2=Tue 3=Wed 4=Thu 5=Fri 6=Sat
0 18 * * 0,1,2,3,6 /usr/sbin/shutdown -h now

Cloud images usually ship set to UTC, so fix the time zone first, for example with sudo timedatectl set-timezone Asia/Tehran (or your own zone). Scheduling pitfalls are covered in our cron job tutorial.

3) Separate your data from the machine's lifetime

The main reason idle servers never get deleted is fear: "What if there's something important on it?" The cure is an archive that lives outside the server:

set -euo pipefail
STAMP=$(date +%F)
DEST=/root/state ; sudo install -d -m 700 "$DEST"

sudo tar -czf "$DEST/state-$STAMP.tar.gz" /var/www /etc/nginx /etc/letsencrypt
# credentials come from ~/.my.cnf so they never land in shell history
mysqldump --single-transaction --routines --events app > "$DEST/app-$STAMP.sql"
sudo chmod 600 "$DEST"/*
scp "$DEST/state-$STAMP.tar.gz" "$DEST/app-$STAMP.sql" user@keeper:/backups/

Don't build the archive in /tmp; that path is readable by every user on the server. The next step is to keep the data on a separate disk: with /var/www on a second disk, rebuilding the machine just means reinstalling the operating system and attaching the same disk. Practice restoring with our Linux server backup tutorial.

4) Cut outbound traffic in order of its effect on the bill

Traffic is the only part of the bill that software optimization can shrink without downsizing the machine. The full configuration is in our VPS bandwidth and traffic guide; here, what matters is the order of impact:

• Images first. According to Google's official WebP documentation, lossy WebP images are on average about 30 percent smaller than JPEGs of the same quality, and lossless WebP images are 26 percent smaller than PNGs. Since images make up the largest share of traffic, that percentage carries straight through to the bill.
• Browser caching second. A Cache-Control header spares returning visitors from downloading the same files again. Use immutable only on files whose names change with every version; otherwise returning visitors never get the new version.
• Compression third. gzip only helps text responses. On JPEG and MP4 it saves nothing and just burns CPU — which costs money too.

5) Slim down the OS image and switch off services you don't need

Every service that starts for no reason takes up RAM, and RAM taken up means buying one size larger. After installation, take a hard look at the list of running services:

systemctl list-units --type=service --state=running
systemd-analyze blame | head -15
ps aux --sort=-%mem | head -10

sudo systemctl disable --now <service-you-do-not-need>

What each line tells you: list-units --state=running lists the services that are running; systemd-analyze blame ranks each unit by how long it took to start at boot — useful for spotting services that have no reason to be there, not for measuring memory; and ps aux --sort=-%mem shows RAM usage.

6) Clean up forgotten snapshots and backups

Snapshots run up costs quietly: they're taken before a big change, and then nobody goes back to them. A simple policy: take one only before a risky change, and delete it the same day.

df -h /
sudo du -xh --max-depth=1 / 2>/dev/null | sort -h | tail -15

journalctl --disk-usage
sudo journalctl --vacuum-time=14d        # keeps only the last 14 days of logs

# 1) list first — read the output before deleting anything
sudo find /backup -type f -name '*.tar.gz' -mtime +14 -print
# 2) only then delete
sudo find /backup -type f -name '*.tar.gz' -mtime +14 -delete

# Debian / Ubuntu — run without -y once and read the removal list
sudo apt-get autoremove --purge
sudo apt-get clean

# AlmaLinux / Rocky
sudo dnf autoremove
sudo dnf clean all

If you run Docker, unused images are the biggest consumer of space. But docker system prune -a doesn't only remove images; it also deletes every stopped container and every unused network.

docker system df                 # where the space actually is
docker image prune -a            # unused images only — safest first step
docker builder prune             # build cache only

# system prune -a ALSO removes every stopped container and unused network:
docker ps -a                     # check this list first
docker system prune -a

7) Consolidate several small services onto one machine

Five small services — three bots, a light API and a personal website — on five separate servers cost five times as much in disks and IP addresses, even though together they use less than one mid-sized machine. For low-risk workloads, consolidation is the fastest way to cut server costs, provided you isolate the services with containers.

8) Watch the usage trend, not just the moment

Financial surprises come from not looking. Check two numbers every week: running hours and gigabytes of traffic.

# Debian / Ubuntu
sudo apt install vnstat -y

# AlmaLinux / Rocky (EPEL)
sudo dnf install -y epel-release && sudo dnf install -y vnstat

sudo systemctl enable --now vnstat
vnstat -m          # monthly traffic table
vnstat -d          # daily breakdown
uptime -p          # how long this machine has been running

vnstat counts from the moment it's installed, so the first month's table is incomplete. The trend matters more than the number: traffic that has grown three months in a row will grow in the fourth as well. Dashboards and automated alerts are covered in our server monitoring tutorial.

9) Build your own budget alert

With pay-as-you-go cloud billing, the only thing standing between you and an unexpected bill is an early warning. Set up a weekly cron job:

# /root/report.sh  (chmod 700 — keeps the token out of crontab)
#!/bin/bash
TOKEN=123456:AAyourtokenhere
CHAT=11111111
# field number differs between vnstat versions - run it once to confirm
MONTH=$(vnstat --oneline | cut -d';' -f11)   # field 11 = total traffic this month
curl -s -X POST "https://api.telegram.org/bot$TOKEN/sendMessage" \
  -d chat_id="$CHAT" \
  --data-urlencode "text=$(hostname) | up: $(uptime -p) | traffic: $MONTH"

# root crontab — weekly report, Saturday 09:00
# 0 9 * * 6 /root/report.sh

Field 11 of the vnstat --oneline output is the total traffic for the current month; fields 9 and 10 are the month's received and sent traffic. --data-urlencode isn't optional: -d doesn't encode the content, so a message containing spaces and | arrives garbled.

10) Actually delete finished test environments

The simplest method, and the one least often followed. When an experiment is over, don't power the machine off — delete it: take a final backup, make sure it can really be restored, and delete the server together with its dependent snapshots.

Hourly server traps that quietly inflate your bill

An hourly server isn't cheap by nature; it's just honest. The bill shows exactly what you built and left running. The defense against most of the traps below is a habit, not a setting.

• The server you forgot. A machine built for a two-hour test that stayed on for six weeks. The only effective defense is a monthly review of your server list.
• The orphaned snapshot. The server has been deleted, but its snapshot or disk is still there, reserving space. After every deletion, check the snapshot list.
• A traffic spike after a release. A large file that suddenly gets downloaded a lot can cost more than several weeks of the server itself. In Nginx, the limit_rate and limit_conn directives turn the spike into a manageable slope.
• Steady long-term load. If a service runs 24 hours a day and has been stable for months, the hourly model isn't necessarily the cheapest option.

When should you not choose an hourly server at all?

An hourly VPS isn't the best choice for every project. In three situations another option makes more sense: when all you need is a small website, when you have a heavy, steady production load, and when you don't have time to manage an operating system. Put the hidden cost of your own time into the calculation, too.

• A small WordPress or company website. If you aren't going to install your own services, shared web hosting with cPanel and DirectAdmin is simpler. We compare the two paths in shared hosting vs VPS.
• A heavy, always-on production service. When the load is steady and has outgrown a mid-sized machine, enterprise solutions with dedicated resources are the better answer.
• When you don't have time to manage a server. An abandoned server that never gets updates is the most expensive option of all. The criteria are in our VPS buying guide.

Cloud cost audit checklist: seven steps every month

A monthly audit means ten minutes for seven checks that catch most bill leaks before they grow: servers nobody owns, the wrong billing model, the wrong size, forgotten snapshots, traffic growth, disks filling up and a wallet balance that won't last the month. Do it at the start of every month, not after a bill has already surprised you.

1. Write one sentence for every active server: "What does this machine do?" Any machine without a sentence is a candidate for deletion.
2. Compare last month's running hours with the break-even point to check you're on the right model.
3. Check peak RAM and CPU use with sar -r and sar -u, and decide whether to move one size down.
4. Review snapshots and backups, and delete anything that has no retention policy.
5. Check the month's traffic with vnstat -m and look at the growth over the last three months.
6. Check disk space with df -h and rein in any log that keeps growing.
7. Compare your wallet balance with next month's estimate, and top up the wallet before the month starts.

Frequently asked questions

How do I estimate next month's hourly server cost?

Multiply the running hours by the full hourly rate, multiply the powered-off hours by the published off-state percentage of that rate, and add the traffic cost on top. Take the hours from last month's itemized transactions rather than from memory, and add 20 to 25 percent for "forgotten days". The first four parts of the bill are tied to time; traffic is tied to data volume. Compare the total with your wallet balance, not with an advertised one-hour price.

If I power off my server, does it still cost money?

Yes. As long as the server exists, its RAM, CPU, disk and IP address stay reserved on the host hardware, so powering off reduces the hourly rate but doesn't bring it to zero; the exact percentage is published in the terms of service and the panel's itemized transactions. To stop the cost completely, delete the server along with its snapshots and attached disks. Rule of thumb: power off for a break of a few days; for a break of several weeks, take a backup and delete.

How do I calculate the break-even point between hourly and monthly billing?

Divide a configuration's monthly rent by its hourly rate; the result is the number of hours a month at which the two models cost the same, provided you delete the server during idle hours. If you only power it off, the break-even point moves lower, because a powered-off server still bills a percentage of the rate. With an off-state rate of one half, the break-even point equals twice that ratio minus 730 hours.

Is an hourly server worth it for an always-on, 24/7 website?

Usually not, except during an evaluation period. A service that runs for months without a break doesn't use the flexibility of hourly billing, so it shouldn't pay for it. But there's a smart use of the hourly model even here: before a long-term commitment, build a server for a few days and spend them measuring steal time, real disk speed and network path quality, using the full checklist in our Iran server quality test guide. That trial costs almost nothing next to a year on the wrong server.

How do I avoid surprise bills with pay-as-you-go billing?

Three layers are enough. First, a monthly review of your server and snapshot lists, so no forgotten resource is left behind. Second, track two key numbers — running hours and monthly traffic — with uptime and vnstat. Third, a weekly automated alert with cron. And a layer zero: top up your wallet only to the month's estimate, no more; the balance limit itself acts as a brake.

Next step

The practical summary: first decide whether you'll delete the server during idle hours or only power it off, because that decision is what moves the break-even line; then read your real running hours. Take the current hourly rate from the pricing calculator and plug it into the formula.

And if you want to test your assumptions — say, by trying one size smaller — create an hourly cloud server at Mehran Host: KVM with NVMe disks in an Iranian datacenter, usually ready in under 60 seconds, with hourly billing that stops once you delete the server.