Docs / Scheduled tasks / Troubleshooting

Troubleshooting missed runs

Scheduled duties are executed by the OpenClaw scheduler; CloudyBot owns ownership, delivery, and thread linking in SQLite. When something looks late or silent, work through the checks below before assuming the job vanished. Hub: scheduled tasks.

Step 1 — Did the job fire at all?

• Run now from the Team Task Board card or Schedule tab. If manual run works but the clock does not, focus on schedule/timezone (below). If manual run also fails, focus on credentials, skills, or plan limits.
• Notification inbox — standalone tasks and most linked duties write a row to the cron notification feed even when you are not watching a thread.
• Last run status on the card — ok vs error with duration; errors often mean tool or credit failure mid-run, not a missed trigger.

New jobs also run once immediately on creation (wakeMode: now) — expect an extra notification when you first save a duty.

Schedule & timezone

• Timezone — dashboard schedules use local time plus an IANA zone (for example America/New_York). Default is UTC if unchanged. A job at “9:00” in UTC is not 9:00 in your local office.
• Cron vs every-N-minutes — Specialist duties often use five-field cron (minimum 15 minutes between fires). Standalone Schedule tasks may use interval mode. See cron syntax.
• Disabled toggle — paused tasks do not fire on the clock. Re-enable from the card or Specialist settings.
• run_limit reached — one-shot follow-ups and limited runs auto-disable after N executions (schedule_followup uses run_limit = 1).

Plan & account limits

• Cron job cap — all rows in cron_jobs count, including Specialist duties. Free: 2; Growth: 6; Pro: 15; Max: 50 (plans.js). You cannot add duties above the cap — delete or upgrade first.
• AI credits exhausted — a triggered run may start then return 429 or a short error if monthly task credits are gone. Check Settings usage; cron chains may soft-stop mid-pipeline (limits FAQ).
• Browser minutes — duties that open the cloud browser fail if browser quota is zero, even when chat credits remain.

Specialist & duty state

• Dismissed or paused Specialist — duties on that employee stop executing until the Specialist is active again.
• Wrong thread for “run now” from chat — the run_task tool may only fire a Specialist duty from that duty’s linked thr_* thread. Use the dashboard Run now button or webhook from elsewhere.
• Editing duties via chat tools — delete_task / toggle_task are blocked for Specialist duties; use Specialist settings so you do not accidentally disable production cron.

Ran but nothing in the chat thread

• thread_mode: standalone — output goes to notifications (and email/WhatsApp if configured), not a sidebar thread. See where results go.
• Broken link — if a task was switched to standalone while a source thread still existed, notifications may work but chat posts stop. Re-link with linked_full + valid source_thread_id.
• Deleted source thread — jobs fall back to standalone automatically when the linked thr_* is removed.

Credentials, skills & tools

• Expired OAuth — reconnect Notion, Gmail, calendar, or other integrations in Settings before the next cron window.
• Skill gating — standalone tasks store an allowlist in skills_json; Specialist duties use template + override. If a tool was removed from the duty, the run may skip that step or fail closed.
• Missing encryption key (self-hosted) — saved credentials require CREDENTIAL_ENCRYPTION_KEY on the API process or PUT /api/user/credentials fails.

Webhook triggers

• URL format — POST https://cloudybot.ai/w/{64-char-hex}; token must be in the path, not query string.
• Rate limit — at most one fire per 60 seconds per job; extra posts return 200 with queued: false silently — do not use webhooks as a tight loop.
• Invalid token — 404 means regenerate from the duty card and update Zapier/Make.
• Body ignored (V1) — webhook payload is not injected into the prompt; the stored duty text always runs.

Platform outages

If status shows degraded API or database readiness, clock triggers may backlog until the gateway returns. External providers (LLM APIs, Browserbase, Stripe) can fail independently — chat login may work while browser-heavy duties error.

Still stuck?

Contact support with: duty name, approximate scheduled time and timezone, whether Run now works, last run status from the card, and your account email. For thread delivery issues, note the target thr_* title and whether notifications still arrive.

Related: general troubleshooting · thread targeting · repo docs/scheduledTasks/Readme.md