DEV Community: bigdomain host

Cron jobs, and the four reasons yours isn't running

bigdomain host — Fri, 30 Oct 2026 19:18:19 +0000

Disclosure: I run Bigdomainhost, an Indian hosting company. This is adapted from a guide on our site.

Cron takes a minute to understand and, sometimes, a week to debug. The idea is trivial: a table of commands, each with a schedule, and a daemon that runs them on time. It has been part of Unix since the 1970s.

The trouble is that a cron job which looks right will often just not run, and cron won't tell you. When that happens it's almost always one of four things. Syntax first, then those four.

The five fields

┌───────────── minute        (0 - 59)
│ ┌─────────── hour          (0 - 23)
│ │ ┌───────── day of month  (1 - 31)
│ │ │ ┌─────── month         (1 - 12)
│ │ │ │ ┌───── day of week   (0 - 6, Sunday = 0)
│ │ │ │ │
* * * * *  /usr/bin/php /home/user/script.php

There are only four operators:

* means every value. * * * * * is every minute.
, is a list. 0 9,17 * * * is 9am and 5pm.
- is a range. 0 9-17 * * * is hourly from 9am to 5pm.
/ is a step. */15 * * * * is every fifteen minutes.

That's the whole language. Anything that looks more complicated is a combination of these.

Schedules you'll actually use

Expression	Runs
`/5 * * *`	Every five minutes
`/15 * * *`	Every fifteen minutes (the usual WP-Cron replacement)
`0 * * * *`	Every hour, on the hour
`30 2 * * *`	2:30am daily, the classic backup slot
`0 3 * * 0`	3am every Sunday
`0 0 1 * *`	Midnight on the first of every month
`0 9 * * 1-5`	9am on weekdays only

One thing people forget: cron runs in the server's timezone. On our servers that's IST, so 30 2 * * * means 2:30am in India. On a cloud VM somewhere else it might be UTC, and your "2:30am backup" quietly runs at 8am IST in the middle of business hours. Run date on the box before you assume anything.

The smallest interval standard cron gives you is one minute. If you need something finer, you need a long-running process or a loop with sleep, not cron. On shared hosting the practical minimum is often five or fifteen minutes, to protect everyone else on the server.

Setting it up

In cPanel

cPanel → Cron Jobs.
Put a real address in Cron Email. Cron mails you anything the command prints. This is how you find out a job has been failing for three weeks.
Pick a Common Setting, or type the five fields yourself.
Enter the command with absolute paths:

/usr/local/bin/php /home/username/public_html/cron.php

Add it, wait for the first run, and check the mail.

Once you've seen it succeed and you're tired of the emails, append >/dev/null 2>&1. Not before. Silencing a job you haven't watched work is how jobs die unnoticed.

On a VPS

# edit your own crontab
crontab -e

# list what is scheduled
crontab -l

# edit another user's crontab
sudo crontab -u www-data -e

System-wide jobs go in /etc/cron.d/, and those files take an extra field: the user to run as, between the schedule and the command.

# /etc/cron.d/backup
30 2 * * * root /usr/local/bin/backup.sh

Copy a line from /etc/cron.d/ into crontab -e (or the other way round) and the user field gets treated as the command, or the command loses its first word. This catches people out constantly.

The four reasons it doesn't run

1. Relative paths

Cron doesn't start in your home directory and doesn't have your shell's PATH. So:

php script.php                              # fails
/usr/local/bin/php /home/user/script.php    # works

Find the real binary with which php and paste exactly what it prints. Same for mysqldump, node, python3, anything.

2. A missing environment

Your interactive shell loads .bashrc. Cron doesn't. If your script depends on an environment variable, it needs to be set in the crontab itself:

PATH=/usr/local/bin:/usr/bin:/bin
30 2 * * * /home/user/backup.sh

3. The script isn't executable

chmod +x /home/user/backup.sh

And make sure the first line is a shebang, #!/bin/bash. Without it, cron may not know how to run the file.

4. An unescaped percent sign

This is the one nobody guesses. In a crontab, % means newline. Everything after the first % gets passed as stdin, not as part of the command. So this:

30 2 * * * tar czf /backups/site-$(date +%Y-%m-%d).tar.gz /home/user/public_html

gets cut off at date +, and you get a broken command with no obvious error. Escape every one:

30 2 * * * tar czf /backups/site-$(date +\%Y-\%m-\%d).tar.gz /home/user/public_html

Or, honestly, put the logic in a shell script and call the script from cron. Then the % problem goes away entirely and you can test the script by hand.

WordPress: replace WP-Cron

WordPress has its own scheduler called WP-Cron, and it isn't cron. It fires when someone loads a page. On a quiet site that means scheduled posts don't publish and backup plugins don't run. On a busy site it fires on every page load, which is its own problem.

You fix both in five minutes. In wp-config.php:

define('DISABLE_WP_CRON', true);

Then add a real cron job every fifteen minutes:

*/15 * * * * /usr/local/bin/php /home/user/public_html/wp-cron.php >/dev/null 2>&1

For five minutes of work, few WordPress changes pay off more. We go into it, and the rest of the WordPress tuning list, in our WordPress speed guide.

Debugging a job that's gone quiet

In the order I'd actually do it:

Run the exact command by hand. Copy it out of the crontab, paste it into a shell. If it fails interactively, cron was never the problem.
Check the cron log. /var/log/syslog on Debian and Ubuntu, /var/log/cron on AlmaLinux and Rocky. If there's no line for your job at the expected time, the schedule or the crontab file is wrong. If there is a line, the command is wrong.
Capture the output. Replace >/dev/null 2>&1 with >> /home/user/cron.log 2>&1 and read the file after the next run.
Test with * * * * *. You find out in a minute instead of tomorrow. Then set the real schedule back.

A quick way to check the log on Ubuntu:

grep CRON /var/log/syslog | tail -20

# if there's no syslog file, ask journald instead
journalctl -u cron --since today

On AlmaLinux and Rocky the unit is crond, not cron.

If you see the job firing there but nothing happens, go back to the four reasons above. Paths and % are the two I'd check first.

Cron is available on every plan we sell, from shared cPanel hosting upwards, and on a VPS you get the full crontab and /etc/cron.d/. The original guide, with a short FAQ, is on our site.

Posted by the Bigdomainhost team. The original version of this guide is on our site.

How much RAM does your VPS actually need? Numbers by workload

bigdomain host — Thu, 29 Oct 2026 16:38:27 +0000

Disclosure: I'm Parth, I run Bigdomainhost, an Indian hosting company, and the price column below is our own plan list. The RAM numbers apply to any host.

Almost every VPS gets bought one size too big or one size too small. Too small looks like WordPress, MySQL and a page builder squeezed into 2 GB, throwing "Error establishing a database connection" every few days. Too big looks like a 32 GB box running a 3 GB workload.

Both are fixable with some simple arithmetic. This post is that arithmetic.

Start with what uses the memory

On a normal LAMP or LEMP server, the RAM goes to a handful of things. Typical ranges:

Component	Typical usage
Minimal Ubuntu / AlmaLinux, no desktop	200-400 MB
MySQL / MariaDB	500 MB to 2 GB
PHP-FPM	40-120 MB per worker
Nginx	50-100 MB
Apache with mod_php	a lot more than Nginx
LiteSpeed	somewhere between the two
Redis	whatever you cap it at, usually 256 MB to 2 GB
cPanel	about 1 GB before you host a single site

Two lines in that table do most of the damage.

The first is PHP-FPM. People look at "40-120 MB" and think it's small. It's per worker. A WordPress site with Elementor or similar sits at the top of that range, so ten workers at 100 MB is a full gigabyte on its own.

The second is the MySQL InnoDB buffer pool. Ideally it holds your entire working data set in memory. If it can't, every query that misses the pool goes to disk and your "slow site" problem is actually a RAM problem wearing a disguise.

Add up the components you actually run, then put 25-30% on top. A server that is full at idle has nothing left for your busiest hour of the day.

Why I size RAM generously and CPU tightly

This is the one opinion I'd defend hardest in this whole post.

When a server runs short of CPU, it gets slow. Requests queue, pages take longer, but they come back.

When it runs short of RAM, it breaks. Linux first starts swapping to disk, which is orders of magnitude slower than memory. When swap is used up too, the kernel's out-of-memory killer picks the largest process and kills it. On a web server the largest process is almost always MySQL. So the visible symptom isn't "slow", it's "Error establishing a database connection" until someone or something restarts mysqld.

CPU pressure degrades. RAM pressure breaks. So if the budget forces a trade-off, take the extra RAM.

Rules of thumb that have held up for us

WordPress, cached: roughly 1 GB per busy site, including its share of MySQL.
WooCommerce: double that. Cart, checkout and My Account can't be page-cached, so every one of those requests hits PHP and MySQL.
Minecraft: about 1 GB per ten vanilla players, plus whatever the modpack says it needs, rounded up.
Tally on Cloud: Windows Server wants about 4 GB before Tally even starts. 8 GB is comfortable for one or two concurrent users.
Node and Python APIs: measure. They vary more than anything else here, and any number I give you will be wrong for your app.

The cheat sheet

Here's how that maps to plan sizes. Prices are our own plans in rupees, excluding 18% GST, because that's what I know. The RAM column is the part that transfers to any host.

Workload	RAM	Our plan (per month)
Static site, small API, dev box	2 GB	₹674
1-3 WordPress sites, cached	4 GB	₹674
Production WordPress + MySQL	8 GB	₹1,348
WooCommerce store	8-16 GB	₹1,348-₹2,696
10-20 sites behind cPanel	16 GB	₹2,696
Redis or Elasticsearch node	16 GB+	₹2,696
Tally on Cloud, 1-2 users	8 GB	₹1,899
Modded Minecraft, 20-40 players	16 GB	₹2,696
CI runners, build servers	16-32 GB	₹2,696-₹5,017

Measure what you're using right now

If you already have a server, don't guess. Three commands tell you most of what you need:

# free memory, human readable
free -h

# the ten biggest processes by memory
ps aux --sort=-%mem | head -11

# is it swapping? (5 samples, 1 second apart)
vmstat 1 5

Two things to read correctly.

In free -h, look at the available column, not free. Linux uses spare memory as disk cache and gives it back on demand. A low "free" number is normal and healthy. People panic over it all the time and it means nothing.

In vmstat, watch the si and so columns (swap in, swap out). If they're non-zero across samples, the box is actively swapping. That's your signal to add memory, not to tune something.

If you want to see how much each PHP-FPM worker is actually taking on your site, rather than trusting my 40-120 MB range:

ps -o rss,cmd -C php-fpm --sort=-rss | head

RSS is in KB. Multiply your typical worker size by pm.max_children in your pool config and you'll know whether your FPM settings can even fit in the RAM you have. (The process name may be php-fpm8.2 or similar depending on the distro, so adjust the -C value.)

Should you add swap?

Yes, 1-2 GB of it. Treat it as an emergency buffer that turns a hard crash into a slow patch. It is not a substitute for RAM. If you're swapping routinely, buy more memory.

On a box without swap, the usual setup is:

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
grep -q '^/swapfile ' /etc/fstab || echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

The grep guard stops you adding a duplicate fstab line if you run it twice. Then free -h again to confirm the Swap row shows 2.0Gi. (On some filesystems fallocate swap files fail swapon; if that happens, create the file with dd instead.)

Is 1 GB ever enough?

For a static site, a small API or a personal project, yes. For WordPress with MySQL on the same machine, it's tight enough that one traffic spike will wake up the OOM killer. If the site matters to anyone, start at 2 GB. For a production WordPress site with the database on the same box, 4 GB is the sensible starting point, and 8 GB once WooCommerce or a dozen client sites are involved.

When CPU does matter more

There are workloads where I'd reverse my advice: video encoding, heavy cron jobs, and game servers. For game servers, single-core speed beats core count. A Minecraft server's main loop mostly runs on one thread, so extra cores don't help it the way they help a pool of PHP workers.

Don't over-buy either

A 32 GB server running 3 GB of workload is money spent on nothing. Our plans resize in place: vCPU, RAM and disk grow with a single reboot and nothing gets reinstalled. If your host can do the same, the right move is to start one size down and move up when free -h and vmstat tell you to, not when a sales page does.

If your host can't resize in place and a move means a full rebuild, that changes the maths. Then I'd buy one size up and accept some waste, because a migration under pressure costs more than the extra RAM.

The full VPS ladder we sell, with Mumbai (BOM-1) and Delhi NCR (DEL-1) locations, is on the KVM VPS page. If you're still deciding whether you need a VPS at all, we also wrote up VPS vs shared hosting, and the original version of this guide is here.

Posted by Parth from Bigdomainhost. The original version of this guide is on our site.