Your first OpenClaw automation: from zero to a working scheduled task in under an hour

This guide builds your first OpenClaw automation from scratch: a scheduled task that runs on its own, does something useful, and reports back. No AI experience required. No code to write. By the end you’ll have a working cron job and understand how to build more.

What an OpenClaw automation actually is

An automation in OpenClaw is a cron job tied to an instruction. When the schedule fires, the agent wakes up, reads the instruction, runs it, and goes back to sleep. The instruction is plain English. You don’t write code. You write what you want the agent to do, the same way you’d write it in a message.

Here’s what distinguishes an OpenClaw automation from other automation tools:

• The executor is an AI agent. The instruction doesn’t have to be a rigid script. “Check the last 24 hours of my email and summarize anything that looks urgent” is a valid automation. A traditional cron job can’t do that. OpenClaw can.
• The output is natural language. Results come back as readable text: a summary, a report, a notification. You don’t parse JSON or read log files.
• It connects to your context. The agent has access to your workspace files, your memory, your configured channels. The automation can read a file you updated yesterday, reference a decision from last week, and send the result to your Telegram.

The tradeoff: because the executor is an AI, there’s a small per-run cost. Most automations cost between $0.001 and $0.05 per run depending on complexity and which model runs them. This guide uses local models (Ollama) for everything that doesn’t require an API model, bringing most automations to $0.00 per run.

Before you build: verify your OpenClaw setup

Paste this into your OpenClaw chat before anything else. It confirms your setup is ready for automations:

Run these checks and tell me the results: (1) Run openclaw status and show me the output. (2) Run ollama list and show me which models are installed. (3) Check if there are any existing cron jobs by running openclaw cron list or equivalent. (4) Tell me the current working directory and what files are in the workspace root.

What you’re looking for: OpenClaw gateway running, at least one Ollama model installed (llama3.1:8b or phi4 work well for automations), and a workspace directory that exists. If any of these are missing, the guide will tell you what to fix as you go.

The local model recommendation for automations

Every automation in this guide uses ollama/phi4:latest as the default model. Phi4 at 14B parameters handles most automation tasks well: summarization, classification, file reading, simple analysis. It runs on your hardware and costs nothing per run. For automations that need higher-quality output (drafting something that goes directly to another person, for example), you’d swap in deepseek-chat at roughly $0.01-0.03 per run. This guide sticks with local models throughout to keep costs at $0.00.

Your first automation: a daily file summary

The first automation is intentionally simple: once a day, read a specific file in your workspace and send you a one-paragraph summary of what’s in it. This is useful on its own (for keeping a daily notes file or log) and teaches every concept you need for more complex automations.

Step 1: Create the file to summarize

Create a file at /home/node/.openclaw/workspace/daily-notes.md with this content:

# Daily Notes
_This file is my running log. I add to it throughout the day._

## 2026-03-25
– Set up my first OpenClaw automation
– Testing the daily summary cron
– Working on: [what you’re actually working on today]

You’ll update this file daily. The automation reads it every morning and sends you a summary. Once the habit is in place, this becomes useful context for starting each day. Your own notes, summarized and delivered to you before you open the file.

Step 2: Set up the cron job

Create a cron job that runs every morning at 8 AM in my local timezone. The task: read /home/node/.openclaw/workspace/daily-notes.md and write a 2-3 sentence summary of the most recent entries. Send the summary to me via Telegram. Use ollama/phi4:latest for this task. Show me the cron job configuration before saving it.

Your agent will show you the cron configuration. Review two things: the schedule (is 8 AM right for your timezone?) and the model (phi4:latest for $0.00 cost). Adjust either before confirming.

Step 3: Test it immediately

Don’t wait for 8 AM to find out if it works. Trigger a manual run first:

Run the daily notes summary cron job right now manually, exactly as it would run on schedule. Show me the output and confirm it was sent to Telegram.

If it works, you should receive a Telegram message with a summary of your daily notes. If something fails, the agent will tell you what went wrong. Common issues and how to fix them are in the troubleshooting section below.

Understanding the cron schedule format

OpenClaw cron jobs use standard cron syntax: five fields that specify minute, hour, day of month, month, and day of week.

• 0 8 * * *: 8:00 AM every day
• 0 8 * * 1-5: 8:00 AM Monday through Friday only
• 0 */4 * * *: every 4 hours
• */15 * * * *: every 15 minutes
• 0 9 * * 1: 9:00 AM every Monday
• 0 8,12,17 * * *: 8 AM, noon, and 5 PM every day

The timezone matters. If your OpenClaw server is in UTC and you’re in New York (ET), 8 AM ET is 0 13 * * * in UTC during Eastern Time and 0 12 * * * during Eastern Daylight Time. Ask your agent to confirm the server timezone before setting schedules:

What timezone is the server running in? Run date and timedatectl to confirm. If I want a cron to fire at 8 AM Eastern Time, what cron expression should I use?

Your second automation: a weekly summary of everything

Once the daily notes automation is running, add a weekly rollup. Every Sunday evening, the agent reads the full week’s notes, identifies themes, and sends a structured summary. This is the automation most people find immediately valuable. It’s the end-of-week review that never actually happens otherwise.

Create a second cron job that runs every Sunday at 7 PM my local time. The task: read the entire /home/node/.openclaw/workspace/daily-notes.md file. Identify the top 3 themes or recurring topics from the past week. List any decisions made or completed. List anything still open or unresolved. Send this as a structured Telegram message with sections for: Themes, Completed, Open Items. Use ollama/phi4:latest. Show me the configuration before saving.

Your third automation: a file watcher for changes

A file watcher cron runs frequently and checks whether a specific file has changed since the last run. This is the pattern behind a lot of useful automations: monitor a file that other processes write to (a log, an output, a shared document) and alert you when something new appears.

Create a cron job that runs every 30 minutes. The task: check if /home/node/.openclaw/workspace/daily-notes.md has been modified in the last 30 minutes by looking at the file’s modification timestamp. If it has been modified, read the new content added since the last check and send me a Telegram message with just the new lines. If it hasn’t been modified, do nothing. Store the last-checked timestamp in /home/node/.openclaw/workspace/tmp/notes-watcher-last-check.txt between runs. Use ollama/phi4:latest.

This pattern (check a file, compare to previous state, alert on change) applies to anything you want to monitor: log files, downloaded reports, shared documents, pipeline outputs.

Troubleshooting common automation problems

The cron runs but nothing arrives on Telegram

The most common cause is a Telegram configuration issue, not a cron problem. Check three things:

Run a test: send me a Telegram message right now with the text “test message from automation check”. If that works, the Telegram integration is fine and the problem is in the cron instruction. If that fails, show me the Telegram plugin configuration (without the bot token) and tell me what error you see.

The cron fires at the wrong time

Timezone mismatch. The server runs in UTC; your schedule expectation is in local time. Fix by recalculating the cron expression for UTC, or by configuring the cron with an explicit timezone if your OpenClaw version supports it:

Show me all my current cron jobs and their schedules. For each one, tell me what time it fires in UTC and what time that corresponds to in America/New_York timezone. If any are wrong, show me the corrected cron expression.

The automation runs but produces poor quality output

phi4:latest at 14B is capable but not perfect. For automations where output quality matters, switch to deepseek-chat. The cost difference for a once-daily automation is under $0.03/day:

Update the daily notes summary cron to use deepseek/deepseek-chat instead of ollama/phi4:latest. Show me the updated configuration. Also update the instruction to be more specific: the summary should start with the date, list exactly 3 key points from the notes, and end with one open question or next action if any are visible in the notes.

The automation fails silently

A cron that fails without notifying you is a cron you don’t know is broken. Add failure handling to every automation:

Update all my cron jobs to include failure handling: if a cron task encounters an error or cannot complete, send me a Telegram message with the error details. The message should include: which cron failed, what it was trying to do, and the exact error. This applies to all existing and future crons.

Building more complex automations

Chaining tasks: output feeds the next step

Once you have basic crons working, the next pattern is chaining: one automation writes output that another automation reads. The content pipeline in the Workshop is an example of this: research writes a brief, the draft cron reads the brief. The same pattern works for any multi-step workflow.

Create a two-step chained automation. Step 1 (runs at 6 AM): read three websites I specify and write a one-paragraph summary of any new content to /home/node/.openclaw/workspace/tmp/morning-research.md. Step 2 (runs at 7 AM): read morning-research.md and write a brief morning update to send to Telegram with the format: “Good morning. Here’s what’s new: [summary].” Use phi4 for step 1 (web reading and summarizing) and deepseek-chat for step 2 (the final message draft). Show me both cron configurations. The three websites are: [you specify them].

Conditional logic: only act if something is true

Automations can include conditions. “Only send an alert if X is true.” “Only proceed if the file has changed.” “Skip this run if I’m in the ‘do not disturb’ file.” Conditional logic keeps automations from being noisy:

Update the weekly summary cron to include a condition: check if /home/node/.openclaw/workspace/daily-notes.md has any entries from the current week. If the file has no entries this week (I didn’t add anything), skip the summary and send me a short Telegram message: “No notes this week. Weekly summary skipped.” If the file has entries, run the full summary as normal.

Using memory across runs

Automations can read and write to OpenClaw memory between runs. This lets an automation track state over time: what it saw last week, what it already alerted you about, what decisions it made previously:

Update the file watcher cron to use memory instead of a tmp file for tracking the last-checked timestamp. After each run, store the current timestamp in memory with the key “notes-watcher-last-check”. At the start of each run, recall that memory to know when the last check was. This is more reliable than a tmp file which can be lost if the workspace is cleared.

What to build after your first three automations

After the daily notes summary, weekly rollup, and file watcher are running, you have the foundational patterns for almost any automation. Here’s what most people build next, in rough order of value:

1. Morning brief: News, email triage, calendar summary, priority list. Covered in the Workshop article on replacing your morning routine.
2. Inbox triage: Classify incoming messages by priority and draft replies for your review. Covered in the AI clone article.
3. Content pipeline: Research, draft, QA, and publish on a schedule. Covered in the Workshop content pipeline article.
4. Spend monitoring: Daily API cost check, alert if over threshold. Covered in the OpenClaw cost articles.
5. Health checks: Verify that key services are running, configurations are correct, and nothing has drifted from baseline.

Each of these is a variation of the patterns in this guide: read something, analyze it, produce output, conditionally alert. Once you understand those four steps, you can build almost any automation that runs within what OpenClaw’s tools can access.

The one rule for automation design

Every automation should have a clear answer to: “What does this do when something goes wrong?” Automations that fail silently are worse than automations that don’t exist. You trust them, act on them, and only discover the problem when you notice you’ve been acting on stale data.

Before activating any automation, add a failure notification. Before trusting any automation’s output, run it manually once and verify the result. Before building a complex chained automation, test each stage individually. This discipline costs 10 minutes per automation and saves hours of debugging later.

List all my current cron jobs. For each one, tell me: does it have failure notification configured? If any don’t, add failure notifications to all of them now. The notification should go to Telegram and include the cron name, the time it failed, and the error message.

Real-world automation examples from operators

These are automations that OpenClaw operators are actually running as of March 2026, adapted from community reports. None of them require paid models. All run on phi4:latest or llama3.1:8b.

The job board monitor

A developer set up a cron that runs twice daily, visits three job boards (scraped via curl and parsed by the agent), and writes any new postings matching their criteria to a JOBS.md file. A second cron fires in the evening, reads JOBS.md for entries added today, and sends a Telegram digest of the day’s matches. Total cost: $0.00/day. The criteria (“Python or TypeScript, remote, senior, no defense contractors”) are in plain English in the cron instruction. No regex, no filters, no code.

Create a cron that runs twice daily at 9 AM and 3 PM. Visit these three URLs using the web_fetch tool: [URL 1], [URL 2], [URL 3]. For each page, extract any job postings that match these criteria: [your criteria in plain English]. Write matches to /home/node/.openclaw/workspace/jobs/JOBS.md in this format: date found, job title, company, URL, one-line description. Skip any posting already in JOBS.md. Use ollama/phi4:latest.

The price tracker

A freelancer tracks rates for their services across competitor sites. The cron visits six competitor pages weekly, extracts pricing information, and writes it to a COMPETITOR-PRICES.md file. A monthly cron reads 90 days of that file and writes a trend summary: “average rates up 12% since January, one competitor dropped entry-level pricing.” This took 20 minutes to set up and replaces a manual process that used to take two hours a month.

Create a weekly cron (Mondays at 10 AM) that visits these pages and extracts current pricing: [list of URLs]. Write what you find to /home/node/.openclaw/workspace/market/COMPETITOR-PRICES.md with the date and the pricing structure for each. If a page blocks scraping or has no pricing visible, note that too. Use ollama/phi4:latest. No Telegram notification needed. I’ll check the file manually.

The contract status checker

A consultant monitors the status of active contracts by checking a shared project management tool via API each morning. The cron reads the API response, compares it to yesterday’s status stored in a state file, and alerts on any status changes. Completed contracts, new assignments, and overdue deliverables each trigger a specific Telegram format. Setup time: 45 minutes including the API authentication.

Create a daily cron at 7:30 AM that calls this API endpoint: [your API endpoint and auth]. Parse the response for project statuses. Compare to the statuses stored in /home/node/.openclaw/workspace/contracts/STATUS-SNAPSHOT.md from yesterday. For any project whose status changed, send a Telegram alert with: project name, old status, new status. Then update STATUS-SNAPSHOT.md with today’s statuses. Use ollama/phi4:latest for parsing and comparison.

The research digest

A researcher runs a Monday morning cron that reads three RSS feeds via curl, extracts titles and abstracts of papers published in the past week that match their research area, and sends a digest sorted by relevance. The cron uses phi4 for relevance scoring (free) and the output is useful enough that the researcher reads it before their coffee is finished.

Every Monday at 8 AM, fetch these RSS feed URLs using curl: [list of feeds]. Parse the XML to extract entries published in the past 7 days. For each entry, rate its relevance to my research interests (described below) on a scale of 1-10. Show only entries rated 6 or above, sorted by score. Send as a Telegram message with title, one-sentence description, and URL for each. My research interests: [plain English description]. Use ollama/phi4:latest.

Model routing for automations: the decision framework

The correct model for an automation depends on two factors: what the task produces and who sees it. Here’s the decision logic as of March 2026:

Use phi4:latest (free, local) when:

• The output is read only by you (personal summaries, status checks, digests)
• The task is classification, extraction, or comparison (not generation)
• The output doesn’t go directly to another person
• The task runs frequently (every 15-30 minutes) where API costs would accumulate
• You’re testing a new automation before committing to a paid model

Use llama3.1:8b (free, local, faster) when:

• Speed matters more than quality (quick status checks, simple file reads)
• The task is simple pattern matching or yes/no decisions
• You’re running very frequent crons (every 5-10 minutes) and phi4’s 14B size is too slow

Use deepseek-chat (~$0.27/1M input) when:

• The output goes directly to someone else (drafted message, report, alert that others act on)
• The task requires nuanced judgment or multi-step reasoning
• The output needs to sound professional and polished
• The task runs once daily or less (cost stays under $0.05/day)

Use claude-sonnet-4-6 (~$3/1M input) when:

• The task is high-stakes and the output directly affects important relationships or decisions
• The task involves complex document analysis or synthesis across multiple long sources
• phi4 and deepseek have both produced unsatisfactory output for this specific task

Review my current cron jobs. For each one, tell me which model it uses and whether that’s the correct choice based on what the task produces and who sees the output. If any crons are using an expensive model where a local model would work, show me the updated instruction with the cheaper model substituted. Present your recommendations before making any changes.

Setting up your automation workspace

A clean folder structure makes automations easier to manage, debug, and expand. Before building more crons, create a standard workspace layout:

Create this folder structure in the workspace if it doesn’t already exist:
/home/node/.openclaw/workspace/automations/ (cron output and state files)
/home/node/.openclaw/workspace/automations/logs/ (one file per cron, appended on each run)
/home/node/.openclaw/workspace/automations/state/ (state files for stateful crons)
/home/node/.openclaw/workspace/automations/output/ (final outputs from completed tasks)
Confirm each directory exists after creating them.

The logs directory is important. Each cron should append one line to its log file on every run: timestamp, outcome (success/failure), and a brief note on what happened. This gives you an audit trail without taking up significant disk space. A log line is typically 100-200 characters; even a cron running every 15 minutes only generates ~400 lines per day.

Update the daily notes summary cron to append a log line to /home/node/.openclaw/workspace/automations/logs/daily-notes-summary.log after each run. Format: [ISO timestamp] | [success/failure] | [brief note: e.g., “summarized 3 entries, sent to Telegram” or “failed: file not found”]. Do this for all future crons by default.

Automation security: what your crons can touch

Every cron instruction runs with the same permissions as your OpenClaw agent. That means a cron can read your config, write to your workspace, send messages to your connected channels, and run exec tool calls. This is powerful. It also means a poorly-written cron instruction can cause problems.

Three rules for safe automation design:

1. Scope the file paths explicitly. Instead of “read the notes file,” write “read /home/node/.openclaw/workspace/daily-notes.md.” Explicit paths prevent the agent from reading the wrong file if directory structure changes.
2. Log what gets written or sent. Any cron that writes files or sends messages should log what it did. If something unexpected gets sent or written, the log tells you exactly what happened.
3. Don’t give crons exec access to sensitive commands unless necessary. A cron that only needs to read files doesn’t need exec tool access. Keep the permission surface minimal for each cron.

Review my current cron job instructions. For each one, tell me: does it use explicit file paths or relative/vague references? Does it log what it writes or sends? Does it use the exec tool, and if so, what commands does it run? Flag anything that looks like a broad permission it doesn’t need. Show the findings before making any changes.

When automations go wrong: debugging approach

When a cron produces wrong output or fails, the debugging sequence is the same every time:

1. Run it manually and watch the live output. Scheduled runs don’t show you what happens in real time. A manual run does.
2. Check the log for the last few runs. Did it succeed before? When did it start failing?
3. Simplify the instruction. Strip the cron down to its first step only. Does that work? Add the next step. Isolate which step breaks.
4. Check the inputs. If the cron reads a file, does the file exist? Is it in the format the instruction expects? Is it empty?
5. Check the outputs. If the cron sends a Telegram message, did the message arrive? If it writes a file, does the file exist and have the right content?

The [cron name] cron isn’t working correctly. Run it manually now and show me every step: what it reads, what decision it makes, what it writes or sends, and the final output. Don’t summarize. Show me the actual intermediate steps so I can see where it goes wrong.

• Daily notes summary (phi4, daily): $0.00/month
• Weekly rollup (phi4, weekly): $0.00/month
• File watcher (phi4, every 30 min): $0.00/month
• Morning brief chained cron (phi4 + deepseek-chat, daily): ~$0.03-0.10/month

Running all four automations in this guide costs under $0.10/month. The value exchange is stark: these four automations save roughly 30-60 minutes of manual work per day, run continuously, without forgetting or getting tired. At current API pricing, that works out to less than $0.003 per hour of work offloaded.

Building a simple automation status dashboard

Once you have four or more crons running, tracking their health manually gets cumbersome. A status dashboard cron reads all the other cron logs once a day and produces a one-page health report:

Every day at 9 PM, read all log files in /home/node/.openclaw/workspace/automations/logs/. For each log file: find the most recent entry, check if the last run was successful or failed, and note when it last ran. Write a summary to /home/node/.openclaw/workspace/automations/HEALTH-REPORT.md with these sections: each cron’s name, last run time, last run status, and any failure note. If any cron shows FAILED in its last entry, send me a Telegram alert before writing the report. Use ollama/phi4:latest.

This pattern makes it obvious when something breaks. Instead of discovering three days later that your morning brief stopped firing, you get a Telegram alert the same evening. The dashboard cron is simple: read files, summarize, alert on failure. It costs $0.00 to run and saves real debugging time. For most operators, this becomes the first cron they check each morning. If the health report looks clean, everything else is running. That one check replaces individually monitoring four or five separate automations. One minute, every morning, full picture. That is worth the 20 minutes it takes to set up.

Ten practical things first-time operators get wrong

These come from common patterns in the OpenClaw community. Knowing them upfront saves time.

1. Building the cron before testing the instruction manually. Always test the instruction as a regular message first. Get it producing correct output conversationally, then turn it into a scheduled task.
2. Not specifying the model. An unspecified model defaults to whatever the session default is, which may be a paid API model. Specify the model explicitly in every cron instruction.
3. Setting the schedule in local time without converting to UTC. The server runs UTC. Your expected time needs to be converted. Confirm with your agent before saving.
4. Forgetting failure notifications. A cron that fails silently is effectively broken. Add Telegram failure alerts to every cron before you forget.
5. Making the instruction too vague. “Summarize my notes” is worse than “Read /path/to/notes.md and write a 2-3 sentence summary of the most recent three entries.” Specific instructions produce consistent output.
6. Using the same file for input and output. A cron that reads and then overwrites the same file can lose data if it fails mid-write. Use separate input and output files, or append rather than overwrite.
7. Running crons too frequently for the task. A daily summary doesn’t need to run every hour. Match the frequency to what the task actually needs.
8. Not testing the failure path. Move the input file, break the API endpoint. Confirm the failure notification fires. Finding out failure handling works only when something breaks is too late.
9. Building complexity before the simple version works. A five-step chained pipeline is built from five one-step crons that each work independently. Build and verify each step before connecting them.
10. Ignoring the logs after setup. The logs tell you whether the cron is doing what you think it’s doing. Read them for the first two weeks after any new automation goes live. You’ll almost always find at least one thing to adjust. Most of the time it’s a timezone offset, a vague instruction producing inconsistent output, or a file path that changed. The log catches all of these on day one instead of day fifteen.

Frequently asked questions

How many cron jobs can OpenClaw run at once?

There’s no hard limit on the number of cron jobs, but overlapping crons that fire at the same time on the same session can queue up. If you have many crons, stagger their schedules by at least a few minutes. A cron firing at 8:00, another at 8:05, and another at 8:10 is cleaner than three firing at 8:00 AM simultaneously. The agent handles one task at a time per session.

Can a cron job interact with external APIs?

Yes, through the exec tool. The agent can run curl commands, call APIs, and process the responses. This is how the content pipeline sends articles to WordPress, how the morning brief fetches weather data, and how advanced automations pull data from external services. The exec tool gives the agent shell access, which means it can interact with any API that has a command-line interface or accepts curl requests.

What happens if the server restarts while a cron is scheduled?

The cron schedules are stored in OpenClaw’s config, so they survive restarts. The agent will resume scheduling from the stored config. However, if a cron was running at the moment of the restart, it does not automatically resume. The next scheduled fire will be the next time the cron expression matches. For critical tasks, add a startup check: a cron that fires 5 minutes after startup and verifies the last run of each important cron completed successfully.

Can I pause a cron without deleting it?

OpenClaw supports disabling cron jobs without removing them. Ask your agent to disable a specific cron by name or ID. It stays in the config but won’t fire until you re-enable it. This is useful for temporarily pausing automations during travel, vacation, or periods when you don’t want notifications.

How do I test a cron without waiting for the schedule?

Tell the agent to run the cron manually by name: “Run the daily notes summary cron now, exactly as it would run on schedule.” The agent executes the task immediately outside of the schedule. This is the correct way to test before a scheduled run and to re-run a task that failed.

What’s the best cron job for someone who’s just getting started?

The daily notes summary in this guide is the right starting point because it’s low stakes (the worst case is a poor summary of your own notes), teaches every core concept (reading files, scheduling, sending notifications), and provides immediate value from day one. Build this one first, watch it run for a week, then add complexity. Every more sophisticated automation is a variation of what you learn here.

Keep Reading: