Can I test a cron job manually?
Yes. You can run a job manually from the dashboard to validate the payload and delivery behavior before waiting for the next scheduled execution.
Feature
Run OpenClaw automation and cron jobs from the dashboard
Schedule recurring work, run jobs manually, and manage cron-based automation from the dashboard instead of stitching it together in the shell.
Lobsterland now exposes hosted cron management directly in the instance Overview tab. Instead of dropping into the instance shell or editing Gateway cron storage manually, you can inspect schedules, payloads, session targets, delivery targets, and recent run state in one readable interface.
What you can do
- See every configured cron job with schedule, execution lane, delivery mode, and latest run state.
- Create and edit scheduled jobs with one-time, interval, or cron-expression schedules.
- Choose main, isolated, current, or custom session targets and set wake mode.
- Switch between agent-turn and system-event payloads with optional model, thinking, and timeout overrides for agent turns.
- Send results to chat, keep them internal, or post them to a webhook from the same form.
- Enable, disable, run, and delete jobs from the dashboard.
- Use the feature for recurring reports, reminders, and operational automation.
OpenClaw cron docsAlways-on agent stack without burnoutCron queue troubleshootingRun-now timeout fix
Real product screenshot
What scheduled work looks like here
Use cron jobs for recurring reports, reminders, checks, and proactive assistant behavior that should happen without a manual prompt each time.
The dashboard turns those jobs into something readable: you can see the schedule, choose the execution lane, update the payload, test a run, and confirm the latest result from one place.
- One-time, interval, and cron-expression schedules
- Timezone-aware calendar scheduling
- Main, isolated, current, and custom named sessions
- Recurring reports
- Scheduled prompts and reminders
- Run-now testing from the dashboard
- Faster iteration than shell-based cron editing
Schedule types and timing
A job can run once at a set time, repeat on a fixed interval, or follow a full cron expression for precise calendars like every weekday at 9am. Scheduling is timezone-aware, so a morning report fires in your local morning rather than in UTC.
Pick the simplest schedule that fits: a one-time job for a single future action, an interval for steady polling, and a cron expression when you need specific days and times.
- One-time jobs for a single future action
- Interval jobs for steady recurring work
- Cron expressions for precise calendars
- Timezone-aware so timing matches your day
Sessions, payloads, and delivery
Each job chooses where it runs and what it sends. The session target can be the main session, an isolated session that does not touch ongoing context, the current session, or a custom named one, with a wake mode for how it engages the assistant.
The payload is either an agent turn — a prompt the assistant reasons over, with optional model, thinking, and timeout overrides — or a system event for lighter triggers. Results can be announced to chat, kept internal, or posted to a webhook, so the same job form covers both visible reports and quiet background automation.
- Session targets: main, isolated, current, or custom
- Agent-turn payloads with model, thinking, and timeout overrides
- System-event payloads for lightweight triggers
- Deliver to chat, keep internal, or send to a webhook
Why the dashboard flow matters
You do not need to manage cron storage files or hand-written gateway payloads just to keep scheduled work running. The hosted UI covers the common lifecycle: create, edit, enable, disable, run, and delete, while also exposing the core execution choices directly.
That includes wake mode, payload type, agent selection, announce vs internal vs webhook delivery, and visible last-run or delivery errors when a job has problems.
When something does go wrong, the linked troubleshooting guides are there for the incident path while this page stays focused on the normal operating flow.
What people automate with cron jobs
Common uses are recurring summaries like a morning briefing or end-of-day report, scheduled reminders, periodic checks that watch something and message you only when it changes, and proactive assistant behavior that should happen on a clock instead of waiting for a prompt. Because delivery can target chat or a webhook, the same scheduler drives both human-facing updates and machine-to-machine automation.
If you are building toward an assistant that runs around the clock, scheduled jobs are one half of the picture; the other is keeping the workload sustainable. Our guide on an always-on agent stack without burnout covers how to combine cron automation with sensible limits so a 24/7 assistant stays useful instead of noisy.
FAQ
What is the biggest benefit of managing cron jobs here?
That you can run OpenClaw scheduled work from a readable dashboard that exposes schedule, session, payload, delivery, and run-state controls instead of stitching them together from storage files and shell commands.
What schedule formats are supported?
One-time runs, fixed intervals, and full cron expressions. Scheduling is timezone-aware, so jobs fire relative to your local time rather than UTC.
Can a job send its result to Telegram, Slack, or a webhook?
Yes. A job can announce its result to chat, keep it internal, or post it to a webhook, all configured from the same job form.
Can I pause a job without deleting it?
Yes. Jobs can be enabled or disabled from the dashboard, so you can pause a schedule temporarily and re-enable it later without recreating it.
What happens if a scheduled run fails?
The dashboard surfaces the latest run state and delivery errors, so you can see when a job had a problem and use the linked troubleshooting guides to resolve it.