> ## Documentation Index
> Fetch the complete documentation index at: https://help.onetsolutions.net/llms.txt
> Use this file to discover all available pages before exploring further.

# Cron Jobs

> Schedule recurring tasks on your web hosting with cron

A cron job runs a command on a schedule. On web hosting, the usual uses are a CMS scheduler, a backup script, or a periodic import — anything that must happen without someone clicking a button.

<Info>
  **Prerequisites**

  * A Web Hosting service with OnetSolutions
  * Access to your cPanel account
  * The command you want to run, and the absolute path to it
</Info>

## Creating a Cron Job

<Steps>
  <Step title="Log in to cPanel">
    Access your cPanel account through the OnetSolutions dashboard.
  </Step>

  <Step title="Open Cron Jobs">
    In the "Advanced" section, click "Cron Jobs".
  </Step>

  <Step title="Set a notification address">
    In "Cron Email", enter the address that should receive the output. Leave it set while you are testing — the output is how you find out the job failed.
  </Step>

  <Step title="Choose the schedule">
    Use "Common Settings" for a standard interval, or fill the five fields individually for anything else.
  </Step>

  <Step title="Enter the command">
    Give the full command with absolute paths, then click "Add New Cron Job".
  </Step>
</Steps>

## Understanding the Schedule

The five fields, in order:

```
* * * * *
│ │ │ │ └── day of week (0-6, Sunday = 0)
│ │ │ └──── month (1-12)
│ │ └────── day of month (1-31)
│ └──────── hour (0-23)
└────────── minute (0-59)
```

Common schedules:

| Schedule              | Fields         | Runs                 |
| --------------------- | -------------- | -------------------- |
| Every 15 minutes      | `*/15 * * * *` | Four times an hour   |
| Hourly                | `0 * * * *`    | On the hour          |
| Daily at 03:00        | `0 3 * * *`    | Once a day, off-peak |
| Weekly, Monday 04:00  | `0 4 * * 1`    | Once a week          |
| Monthly, 1st at 05:00 | `0 5 1 * *`    | Once a month         |

## Writing the Command

Cron runs with a minimal environment. It does not know your shell aliases, and it does not necessarily resolve `php` to the version your site uses. Use absolute paths for both the interpreter and the script:

```bash theme={null}
/usr/local/bin/php /home/username/public_html/cron.php
```

To keep a log of what happened rather than relying on email:

```bash theme={null}
/usr/local/bin/php /home/username/public_html/cron.php >> /home/username/cron.log 2>&1
```

The `2>&1` is what captures errors. Without it the log records the successful output and silently drops the failures, which is the opposite of useful.

To run a job silently once it is proven, discard the output:

```bash theme={null}
/usr/local/bin/php /home/username/public_html/cron.php > /dev/null 2>&1
```

<Warning>
  Do not set a job to run every minute unless it genuinely needs to. Overlapping runs of a slow script pile up, consume the account's resources, and can take the site down on their own. If a job might run long, have the script exit early when a previous run is still active.
</Warning>

## WordPress and Similar CMSs

WordPress schedules its own tasks through `wp-cron.php`, triggered by visitor traffic. On a low-traffic site, that means scheduled posts and backups fire late or not at all.

The usual fix is to disable the traffic-driven trigger and run it from cron instead:

```php theme={null}
// In wp-config.php
define( 'DISABLE_WP_CRON', true );
```

```bash theme={null}
# Then a cron job, every 15 minutes
/usr/local/bin/php /home/username/public_html/wp-cron.php > /dev/null 2>&1
```

## Troubleshooting

<AccordionGroup>
  <Accordion title="The job never runs">
    Check the paths first: a command that works when you type it in a terminal often fails under cron because it relied on your shell environment. Use absolute paths everywhere, including the interpreter.
  </Accordion>

  <Accordion title="The job runs but does nothing">
    Redirect the output to a log with `>> /path/to/cron.log 2>&1` and read it after the next run. A script that fails on a missing file or a database connection says so there.
  </Accordion>

  <Accordion title="You receive an email on every run">
    Cron emails any output, including normal output. Once the job is proven, append `> /dev/null 2>&1` to silence it, or clear the "Cron Email" field.
  </Accordion>

  <Accordion title="The timing looks wrong by an hour or two">
    Cron follows the server's timezone, which may not be yours. Work out the schedule in server time, and remember that daylight saving shifts it twice a year.
  </Accordion>
</AccordionGroup>

<Tip>
  Test the command manually before scheduling it. A cron job that fails silently at 03:00 is far harder to diagnose than the same command failing in front of you.
</Tip>