Is it safe to run cron jobs and my web app on the same Droplet, or should they be separated?

Question

I have a Node.js web app running on a Droplet and I recently added a few cron jobs for things like sending digest emails, cleaning up old records, and generating reports. Everything runs on the same Droplet right now.

I have noticed occasional slowness during the hours the cron jobs run, and I am wondering if this is a bad practice that will bite me as traffic grows, or if it is fine for a small to medium sized app.

Bobby · Answer

Hi there, Running cron jobs and a web app on the same Droplet is fine for small to medium apps, it is not inherently bad practice. The slowness you are seeing is resource contention, and the fix is usually scheduling and resource limits rather than separating machines. A few things worth checking: Are your cron jobs and peak traffic overlapping? Digest emails and report generation are classic candidates for running at low-traffic hours (2-4am) rather than whenever is convenient. If they are currently running during business hours, that alone might explain the slowness: crontab -l Check what resources the cron jobs are actually consuming while they run: top Look specifically at whether it is CPU or memory pressure. A report generation job that loads a large dataset into memory can starve your web app’s available RAM even if CPU looks fine. If your cron jobs are single-threaded Node scripts, they can block the event loop if they are CPU-heavy, which affects your web app’s responsiveness even on a multi-core Droplet, since Node itself runs on one thread by default. Consider using worker threads or spawning the cron job as a separate node process rather than running it in-process with your web server: node scripts/digest-email.js & If you want to double check your cron expressions are actually firing when you think they are, this cron expression simulator shows you the next actual run times in your timezone rather than guessing from the syntax, worth using before assuming your schedule is the problem. The real threshold for separating cron jobs onto their own Droplet is when the jobs themselves need significant dedicated resources (heavy report generation, large batch processing) or when you need independent scaling. For occasional digest emails and cleanup tasks, better scheduling usually solves it without adding infrastructure.

alexdo · Answer

Hi there, To add a few things to Bobby’s answer, starting with how the jobs are actually scheduled, because that changes what the problem is. If they are in the system crontab (crontab -e), each job already runs as its own process, so it cannot block your web app’s event loop. The slowness then comes from competing for CPU, memory, disk or the database. If they are scheduled from inside the app with a library like node-cron, they run in the same process as your web server, and a heavy report really can stall requests. In that case, moving them to the system crontab as separate scripts is the first fix. It also avoids a less obvious problem: if you ever run the app under PM2 cluster mode with several instances, an in-process scheduler fires once per instance, and your users get the digest email two or four times. For jobs in the system crontab, you can tell the kernel they are less important than the web app without changing any code: 0 3 * * * flock -n /tmp/digest.lock nice -n 19 ionice -c3 /usr/bin/node /var/www/app/scripts/digest-email.js >> /var/log/digest.log 2>&1 nice -n 19 gives the job the lowest CPU priority, and ionice -c3 puts it in the idle I/O class, so it only gets disk time when nothing else is asking for it. flock -n skips a run if the previous one is still going, which matters once the reports get slower as your data grows. Without it, a job that runs longer than its interval starts piling up copies of itself, and that is often when “occasional slowness” turns into an outage. Two more things to check before moving anything to another Droplet: Is the database the real bottleneck? A cleanup job running one big DELETE ... WHERE created_at < ... can lock rows and saturate disk I/O on the database, and if the database lives on the same Droplet the web app feels it immediately. Deleting in batches of a few thousand rows, with a short pause in between, usually fixes that. nice does not help here, because the work happens inside the database process, not in your script. What timezone does the server use? Run timedatectl. If the server is on UTC and your users are not, “3am” in the crontab may land in someone’s busy hours. If the jobs are separate processes, run at a lower priority, do not overlap, and the slowness is still there, that is the point where a second small Droplet for jobs starts to make sense. Regards

Become a contributor for community

DigitalOcean Documentation

Resources for startups and AI-native businesses

The developer cloud

Start building today

Report this

Is it safe to run cron jobs and my web app on the same Droplet, or should they be separated?

Related questions

How do I set up log rotation properly so my Droplet doesn't run out of disk space?

Docker Networking Explained: How Containers Talk to Each Other

How do I debug a broken deployment on a DigitalOcean Droplet when I have no idea what went wrong?

Any good resources to learn Linux commands in an interactive way?

Please verify the note as given in the cp command section, I think author is talking about cp command rather than mv command.

What's the best way to get comfortable with the Linux command line as a beginner?

Why apt-get changelog Is Still Relevant Today

Best practices for reducing Docker image size for Node.js apps?

How can I securely store environment variables like API keys in my Docker containers?

High CPU Usage Issue

How to Persist Data in Docker Containers?

How to talk with other users connected to the Server

Report this

Is it safe to run cron jobs and my web app on the same Droplet, or should they be separated?

Related questions

How do I set up log rotation properly so my Droplet doesn't run out of disk space?

Docker Networking Explained: How Containers Talk to Each Other

How do I debug a broken deployment on a DigitalOcean Droplet when I have no idea what went wrong?

Any good resources to learn Linux commands in an interactive way?

Please verify the note as given in the cp command section, I think author is talking about cp command rather than mv command.

What's the best way to get comfortable with the Linux command line as a beginner?

Why apt-get changelog Is Still Relevant Today

Best practices for reducing Docker image size for Node.js apps?

How can I securely store environment variables like API keys in my Docker containers?

High CPU Usage Issue

How to Persist Data in Docker Containers?

How to talk with other users connected to the Server