Cron vs systemd timers: how to schedule tasks on a Linux server

Published on 2026-10-26 by frfrand

Differences between cron and systemd timers for backups and automation

Cron vs systemd timers: how to schedule tasks on a Linux server

You need to generate a summary every night or clean temporary files once a week. You can use cron, but on modern Ubuntu there are also systemd timers. It's not so much a fight: what matters is which one integrates better with logs, permissions, and execution of your service.

I'll show you where the problem lies, how to check it without guessing, and what I would do in an application that actually has users. You don't need to memorize an entire manual to solve a specific failure.

What cron vs systemd timers mean in practice

Cron uses time expressions and runs programs under a user. systemd timers activate service units and offer integration with the journal, dependencies, and policies like Persistent=true for certain calendar tasks that were missed while the system was off.

A clarification before touching the server: if the project is already in production, save the state you found and check which user and machine you are going to run the commands on. Working as root without need and changing several things at once makes it harder to find the cause of an error.

Useful commands to get started

# Ver timers activos
systemctl list-timers --all
# Ver una unidad concreta
systemctl status mi-tarea.timer
journalctl -u mi-tarea.service
# Cron del usuario actual
crontab -l
# Ejemplo de calendar en un timer
# OnCalendar=daily

Paths, unit names, and domains are examples. Adapt them to your service. If a command requires administrator permissions, check what changes and why. Diagnostic queries should come before modifications.

Step by step, with checks

Write first a command that works manually and has the correct exit code.
If you use cron, define absolute paths: the environment is not the same as the interactive shell.
If you use systemd, separate mi-tarea.service from the timer and configure a non-privileged user.
Test the service manually before activating its timer.
Verify time, time zone, logs, retry policy, and risk of overlapping executions.

After each step, verify an observable result: a status, a file, an HTTP response, or a log entry. If you find an unexpected message, save it to investigate instead of hiding it with repeated restarts.

Real example: an application that needs maintenance

A tours backend needs to generate a daily report without blocking the API. A separate systemd service with timer allows viewing each execution in journalctl and granting only the credentials it needs.

At the end, test the full path: enter through the domain, call the API, write a test data point, and verify that the information remains after a controlled restart. A server that "starts up" is not always an application that works.

Mistakes worth avoiding

A timer does not automatically make a task idempotent. If you run a charge or a mass email twice, you need to protect the business logic.

It is also important that credentials do not end up in terminal history, logs, shared files, or screenshots. For users and services, use minimum permissions and document who can revoke access.

How ArduMaker fits into this scenario

ArduMaker allows you to manage scheduled tasks on VPS. Recording the command, person in charge, schedule, and result helps determine if a report was actually executed.

ArduMaker can help you manage VPS, deploy repositories, and work with services, databases, and domains from the same platform. It does not replace what we just explained about Linux: precisely for that reason, it is worth understanding diagnostics and having a way to repeat them.

When it is worth automating

If the task repeats, document the manual procedure and its checks first. Then consider a script or a scheduled task with visible errors, logs, and limited permissions. Do not automate a command that you do not yet know how to recover when something goes wrong.

Frequently asked questions

Can I try it without affecting customers? In many cases, yes: a staging VPS or a separate test service allows you to validate the configuration before changing production.

How do I know if it went well? Check logs and a functional operation, not just that the command ended with exit code zero.

When do I need more resources? When metrics indicate CPU, RAM, disk, or connection saturation. A configuration failure is rarely fixed by hiring more memory.

References

In one sentence: first understand the error, then change one concrete thing and check its effect. That discipline saves you many hours of support.