For example, a cron job might synchronize inventory every 15 minutes, send a daily sales report at 8:00 AM, or remove expired records overnight.
Cron originated in Unix-like operating systems, but the same scheduling concepts are used in modern cloud services and backend platforms.
The key distinction is that cron determines when a task runs, while your application determines what the task does.
When should you use a cron job?
Cron jobs are useful for recurring work that doesn’t require someone to initiate each operation manually.
| Use case | Example | Typical schedule |
|---|---|---|
| Database maintenance | Delete expired sessions or temporary records | Every night |
| Data synchronization | Retrieve inventory updates from an external API | Every 15 minutes |
| Notifications | Send subscription renewal reminders | Daily |
| Reporting | Generate sales or usage summaries | Every morning |
| System maintenance | Run backups or rotate logs | Daily or weekly |
| AI workflows | Categorize support tickets using an AI model | Every morning |
These tasks have different purposes, but they share one requirement: work needs to happen automatically according to a schedule.
For applications that also need event-triggered workflows, cron is only one part of a broader backend automation strategy.
How do cron jobs work?
A traditional cron job has three components:
- Scheduler: A background service, commonly called the cron daemon, checks when tasks are due to run.
- Schedule: A cron expression specifies when each task should execute.
- Command: A script or program performs the actual work.
Imagine an application that sends a daily sales report.
At 8:00 AM, the scheduler launches a script that retrieves sales data, generates the report, and sends it to the appropriate recipients.
The scheduler doesn’t need to understand the reporting logic. It only needs to know when to execute the command.
This separation allows cron to automate many types of backend operations.
How do you read cron syntax?
A standard cron expression uses five fields to define when a task should run.
* * * * *
│ │ │ │ │
│ │ │ │ └── Day of week (0–7)
│ │ │ └──── Month (1–12)
│ │ └────── Day of month (1–31)
│ └──────── Hour (0–23)
└────────── Minute (0–59)
Each field represents a different unit of time.
| Field | Allowed values | Meaning |
|---|---|---|
| Minute | 0–59 | Minute of the hour |
| Hour | 0–23 | Hour of the day |
| Day of month | 1–31 | Calendar day |
| Month | 1–12 | Month of the year |
| Day of week | 0–7 | Weekday, with Sunday commonly represented by 0 or 7 |
An asterisk (*) means every possible value for that field.
For example:
* * * * *runs every minute.0 3 * * *runs every day at 3:00 AM.0 9 * * 1-5runs at 9:00 AM, Monday through Friday.
Note: Cron syntax varies by implementation. Traditional Unix cron uses five time fields, while some schedulers support additional fields for seconds or years. The interaction between day-of-month and day-of-week fields can also vary, so verify schedules that constrain both.
Common cron job examples
These examples use traditional five-field cron syntax.
| Cron expression | Schedule |
|---|---|
* * * * * | Every minute |
*/5 * * * * | Every 5 minutes |
*/15 * * * * | Every 15 minutes |
0 * * * * | Every hour |
0 0 * * * | Every day at midnight |
0 3 * * * | Every day at 3:00 AM |
0 9 * * 1-5 | Every weekday at 9:00 AM |
0 9-17 * * 1-5 | Every hour from 9:00 AM through 5:00 PM on weekdays |
0 0 * * 0 | Every Sunday at midnight |
0 0 1 * * | First day of every month |
0 0 1,15 * * | First and 15th day of every month |
0 0 1 1 * | Every January 1 |
The exact execution time depends on the scheduler’s configured time zone.
You can use Crontab Guru to translate common cron expressions into plain English and check schedules before deploying them.
What do special characters mean in cron expressions?
Cron expressions use four common operators.
| Character | Meaning | Example |
|---|---|---|
* | Every value | * * * * * runs every minute |
/ | Repeating interval | */10 * * * * runs every 10 minutes |
- | Range | 0 9-17 * * * runs hourly from 9 AM through 5 PM |
, | Multiple values | 0 9,17 * * * runs at 9 AM and 5 PM |
Some implementations also support shortcuts such as @hourly, @daily, @weekly, @monthly, and @yearly.
Support for these shortcuts varies by scheduler.
How do you create a cron job in Linux?
On Linux systems that use cron, developers typically configure scheduled tasks using the crontab command.
1. Open the crontab editor
Run:
crontab -e
This opens the current user’s cron configuration.
2. Add a scheduled command
For example, to run a backup script every day at 2:00 AM:
0 2 * * * /home/app/scripts/backup.sh
The first five fields define the schedule. The final path identifies the script.
3. Save and verify the configuration
After saving, cron uses the updated schedule.
To list the current user’s configured jobs:
crontab -l
4. Capture execution logs
Scheduled tasks often run without anyone actively monitoring them.
You can redirect script output to a log file:
0 2 * * * /home/app/scripts/backup.sh >> /home/app/logs/backup.log 2>&1
This captures standard output and errors, assuming the destination directory exists and is writable.
Logging makes it easier to investigate failures.
For a beginner-friendly introduction to scheduling automated tasks, see our Beginner’s Guide to Cron Jobs.
What’s the difference between cron jobs, background jobs, and webhooks?
Cron jobs, background jobs, and webhooks all automate work, but they are triggered differently.
| Mechanism | Trigger | Best use case |
|---|---|---|
| Cron job | Scheduled time or interval | Recurring reporting, maintenance, synchronization |
| Background job | Application action or queued work | Asynchronous or long-running processing |
| Webhook | External event | Payment notifications, third-party integrations |
| API request | Direct client request | Operations requiring an immediate response |
For example, generating a monthly account summary is a good fit for cron.
Processing a file immediately after upload is better suited to an event-triggered background job.
When a payment provider sends a notification that a transaction has completed, a webhook is generally more appropriate than repeatedly checking for updates.
Use cron when the schedule determines when work should happen. Use event-driven execution when a specific event should trigger the work.
What can go wrong with cron jobs?
Cron syntax is relatively simple, but reliable scheduled execution requires more than a valid expression.
| Problem | Common cause | Recommended fix |
|---|---|---|
| Job runs at the wrong time | Incorrect scheduler time zone | Verify time zone and daylight saving behavior |
| Script works manually but fails in cron | Missing environment variables or relative paths | Define the required environment and use absolute paths |
| Permission errors | Cron runs under an account without required access | Check ownership, permissions, and execution identity |
| No evidence of execution | Output isn’t captured | Add execution logging and monitoring |
| Overlapping runs | A task takes longer than its scheduling interval | Use concurrency controls, locks, or queues |
| Duplicate processing | Repeated or overlapping executions | Make the operation idempotent |
Why does idempotency matter?
An idempotent operation can run more than once without producing unintended duplicate effects.
For example, a subscription reminder task should check whether a reminder has already been sent before sending another.
This matters because scheduled tasks may overlap, be retried, or execute again after a partial failure.
For important workflows, also plan for API timeouts, expired credentials, failed executions, and missed schedules.
Can you run cron jobs without managing a server?
Yes. Traditional cron runs on infrastructure where developers configure scheduled commands, but many modern platforms provide managed scheduling.
Examples include Kubernetes CronJobs, cloud schedulers, and backend platforms that support recurring application logic.
The underlying concept remains the same: execute work automatically at a scheduled time.
What changes is how developers configure schedules, define tasks, and manage execution.
With a managed backend, scheduled tasks can interact with application data, APIs, and business logic without requiring a separate Linux server or crontab configuration.
How do you create scheduled background tasks in Xano?
Xano provides scheduled background tasks that allow developers to automate recurring backend workflows without managing their own cron server.
Instead of writing a shell script, you define the task’s logic using Xano’s Function Stack and configure when it should run.
A background task can query application data, execute functions, apply conditional logic, and make external API requests.
Example: Send subscription renewal reminders automatically
Imagine you’re building a subscription application and want to remind customers when their subscriptions are approaching expiration.
You can implement this as a scheduled background task.
| Step | What you configure in Xano |
|---|---|
| 1. Create the task | Open Background Tasks in the workspace Library and create a new task |
| 2. Define the logic | Query subscriptions expiring within the next three days |
| 3. Prevent duplicates | Exclude customers who have already received the reminder |
| 4. Send the notification | Use an external API request to call your email provider |
| 5. Record the result | Update the relevant records to track successful delivery |
| 6. Schedule and test | Configure the recurring schedule, test execution, and activate the task |
Once configured, the workflow can run automatically without requiring a user to trigger an API request.
The advantage is that the scheduled task runs within the same backend environment as your application’s data and business logic.
For a step-by-step walkthrough, see Background Tasks (Cron Jobs) in Xano. For a deeper understanding of the business logic behind scheduled workflows, explore Functions: Data Transformation and Business Logic.
What about tasks that run on a specific date?
Not every scheduling requirement involves running a task at the same interval indefinitely.
For example, an application may need to update customer credits on the first day of each month.
One approach is to run a recurring background task and use conditions to determine whether an action should execute.
A daily task could check whether the current date is the first day of the month before updating account credits.
This combines a recurring schedule with application-specific business rules.
When should you avoid cron jobs?
Cron is useful for predictable, recurring work, but it isn’t the right tool for every automation. Consider alternatives when:
- An operation must happen immediately after an event. Webhooks or event handlers may be more appropriate.
- A user needs an immediate response. A direct API request may be better.
- A workflow has complex dependencies. Queues, retries, and orchestration may be needed.
- A system requires continuous processing. Persistent workers or event-driven systems may be more suitable.
The goal is to choose the execution mechanism that matches the workflow rather than use cron for every background operation.
Common questions about cron jobs
Automate recurring backend work without managing cron infrastructure
Cron jobs solve a simple but essential problem: running work automatically at the right time.
Whether you’re cleaning up records, synchronizing external systems, generating reports, or initiating recurring AI workflows, scheduled execution is a foundational backend capability.
But the schedule is only part of the solution. Your application still needs reliable business logic, access to data, error handling, and visibility into execution outcomes.
Xano brings scheduled background tasks together with the backend capabilities those workflows depend on, allowing developers to automate recurring operations without maintaining a separate cron server.
