OpenClaw Cron Jobs Not Working: Troubleshooting Guide [2026]

Quick Diagnostic Steps

Before diving into individual causes, run through this quick diagnostic checklist. It will help you identify the problem in most cases within a few minutes.

Step 1: Check if OpenClaw is running.

# Docker
docker compose ps

# systemd
sudo systemctl status openclaw

If OpenClaw is not running, your cron jobs obviously will not fire. Fix the underlying issue first.

Step 2: Check the logs for cron activity.

# Docker
docker compose logs openclaw 2>&1 | grep -i "cron"

# systemd
journalctl -u openclaw --since "1 hour ago" | grep -i "cron"

If you see cron entries in the log, the scheduler is running. If you see entries at unexpected times, you have a timezone issue. If you see no cron entries at all, the scheduler may not be starting.

Step 3: Check your OpenClaw version.

openclaw --version
# or
docker compose exec openclaw openclaw --version

If you are running 3.22.x, you may be hitting the known plugin injection bug. Update to 3.23+.

Step 4: Check the dashboard. Open the OpenClaw web dashboard, navigate to Automation/Cron Jobs, and verify that your jobs are listed and showing as "Active."

Cause 1: Timezone Mismatch

This is the single most common cause of "cron jobs not working." In reality, the cron job is working — it is just running at a different time than you expect.

OpenClaw's cron scheduler uses the timezone set in the TZ environment variable. If TZ is not set, it defaults to UTC. If you are in New York (UTC-5) and set a cron job for 0 8 * * * (8 AM), it runs at 8 AM UTC — which is 3 AM Eastern Time. Not what you intended.

The fix: Set the TZ variable in your .env file:

# .env
TZ=America/New_York

Common timezone values:

• America/New_York — US Eastern
• America/Chicago — US Central
• America/Denver — US Mountain
• America/Los_Angeles — US Pacific
• Europe/London — UK
• Europe/Berlin — Central Europe
• Asia/Tokyo — Japan
• Australia/Sydney — Australia Eastern

After setting the timezone, restart OpenClaw. Verify it took effect by checking the logs — the timestamps should now match your local time.

For Docker users, you can also set the timezone in docker-compose.yml:

services:
  openclaw:
    environment:
      - TZ=America/New_York

Cause 2: Plugin Injection Bug (3.22)

OpenClaw 3.22 introduced a plugin injection system that allows skills to register themselves with the agent at startup. Unfortunately, a timing bug in this release causes cron-triggered skills that were installed via plugin injection to fail silently. The skill loads into memory, but its cron trigger does not get registered with the scheduler.

This affects skills installed from ClawHub using the openclaw skill install command. It does not affect skills that are manually configured in the cron settings.

How to identify this bug: You see the skill listed in the Skills section of the dashboard, but the Cron Jobs section does not show a corresponding trigger for it. Or the cron trigger shows up but has a "pending" or "unregistered" status.

The fix: Update to OpenClaw 3.23 or later, which resolves the plugin injection timing issue:

# Docker
docker compose pull && docker compose up -d

# npm
npm update -g openclaw

# Verify
openclaw --version

Temporary workaround if you cannot update immediately: manually register the cron trigger in the dashboard. Go to Automation, click "Add Cron Job," select the skill, and enter the cron expression. This bypasses the plugin injection system and registers the trigger directly.

Cause 3: Docker Restart Resets Scheduler

If your Docker container restarts unexpectedly (due to an OOM kill, a host reboot, or Docker updating), the OpenClaw cron scheduler reinitializes. During reinitialization, cron jobs that were scheduled to run during the downtime are skipped — they do not fire retroactively.

More importantly, if your container does not have a restart policy, it may not come back up at all after a restart.

The fix: Ensure your docker-compose.yml has a restart policy:

services:
  openclaw:
    restart: unless-stopped

Also check Docker's memory limits. If the container is being OOM-killed, increase the memory limit or reduce OpenClaw's memory usage by disabling unused skills and plugins.

# Check if the container was OOM-killed
docker inspect openclaw | grep -i oom

Cause 4: Cron Syntax Errors

Cron expressions follow a specific format and errors are not always obvious. OpenClaw uses the standard five-field cron syntax:

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

Common mistakes:

• 8 0 * * * means 12:08 AM, not 8 AM. The correct expression for 8 AM is 0 8 * * *.
• * 8 * * * runs every minute from 8:00 to 8:59 (60 times), not once at 8:00.
• 0 0 * * 7 does not work on all systems — some treat Sunday as 0, others as 7. Use 0 0 * * 0 for Sunday to be safe.
• Using */5 8-17 * * 1-5 is valid (every 5 minutes during business hours on weekdays). Spaces must separate each field.

Validate your expressions. Use an online cron expression validator like crontab.guru to verify your expression does what you think it does before adding it to OpenClaw.

Cause 5: Jobs Disabled in Dashboard

OpenClaw's web dashboard has a toggle for enabling and disabling individual cron jobs. It is possible to accidentally disable a job, especially after an update or configuration change.

Open the dashboard, go to Automation or Cron Jobs, and check the status of each job. A disabled job shows a grey toggle or "Inactive" status. Click the toggle to re-enable it.

Also check if there is a global cron toggle. Some OpenClaw configurations have a master switch that enables or disables all scheduled automation. Look in Settings for "Enable Automation" or "Enable Cron Scheduler."

Cause 6: API Failures Silently Breaking Jobs

A cron job can fire successfully (the scheduler triggers it on time) but fail during execution because the underlying API call fails. This can look like "the cron job didn't run" when in fact it ran but produced no visible output.

Common API failure causes:

• Rate limit hit: If multiple cron jobs fire simultaneously, they may all hit the API rate limit. See our rate limit guide.
• Invalid API key: A rotated or expired API key causes all API calls to fail. Check your .env file.
• Provider outage: If Anthropic, OpenAI, or your provider is down, cron jobs trigger but fail at the API call stage.
• Network issue: If your server loses internet briefly during the cron execution window, the job fails.

Diagnostic: Check the detailed logs for the time the cron job should have fired. Look for error messages after the "cron triggered" log entry. These will usually contain the API error (429 for rate limit, 401 for auth failure, 503 for provider outage).

How to Test Cron Jobs

Don't wait for a cron schedule to verify your job works. Test it manually:

# Run a skill directly (same as what the cron job triggers)
openclaw run your-skill-name

# Or through Docker
docker compose exec openclaw openclaw run your-skill-name

If the manual run works but the cron trigger doesn't, the problem is with the scheduler, not the skill. If the manual run also fails, fix the skill first before troubleshooting the cron.

You can also create a test cron job that runs every minute to verify the scheduler is working:

* * * * * openclaw run test-ping

Create a simple test-ping skill that sends you a message. If you receive a message every minute, the scheduler works. Delete the test job once verified.