A morning brief that takes 30 seconds to read is not a summary. It is a deliberate design. Most AI-generated daily briefings fail the same way: too long, too general, too much context you already have, and buried inside it somewhere is the two things you actually needed to know. This article covers how to build a morning brief with OpenClaw that delivers only what matters, fires automatically before you wake up, and lands in whatever channel you actually check first. The setup takes about 20 minutes. After that it runs itself every day.
TL;DR
- Use a cron job with an agentTurn payload to fire each morning at a fixed time. The cron job is the reliable delivery mechanism that does not depend on you remembering to trigger it.
- Design for 5 bullets max. Each bullet one sentence. No context, no explanation. Just what you need to act on.
- Deliver to wherever you actually look first. Telegram, Discord, or whichever channel you open before anything else. Not wherever is easiest to configure.
- The brief should answer one question: What do I need to know or do today that I would not already know without this?
Throughout this article you will see indented blocks like the ones below. Each one is a command you can paste directly into your OpenClaw chat. Your agent will run it and report back. You do not need to open a terminal or edit any files manually.
What makes a morning brief actually useful
The morning brief fails when it is designed around what is easy to generate rather than what is useful to receive. An agent can write five paragraphs of context on any topic. That is not a brief. A brief answers the question: what do I need to know or act on today that I would not already know without reading this? Everything else is noise that dilutes the signal.
The format constraint forces the content discipline. Five bullets, one sentence each, no explanation unless the explanation is the actionable part. If a bullet requires more than one sentence to be useful, the information does not belong in a morning brief. It belongs in a separate report or a direct alert for that specific topic. The brief is not a place to surface everything interesting. It is a place to surface the five things with the highest cost of missing them today. The cost of missing something is the filter that decides what makes the cut. If missing a piece of information would not meaningfully change your actions today, it does not belong in the brief.
Before I set up a morning brief, help me design what it should contain. My daily context is: [describe your work, projects, monitoring needs, timezone]. Based on this, what are the five categories of information that would have the highest value to surface every morning? For each category, give me one example bullet that shows what good looks like: specific, actionable, one sentence, no padding.
The most common categories that work well in morning briefs: outstanding tasks from the previous day that rolled over, any new mentions, alerts, or messages that arrived overnight, key metrics or status indicators for active projects, upcoming deadlines or time-sensitive items within 48 hours, and one piece of context that changes how you approach the day (a rate limit hit, an API down, a key date). Everything else is optional and should be cut if it is not consistently actionable. The brief is not a place to surface everything interesting. It is a place to surface the five things with the highest cost of missing them today. That cost is the filter that decides what makes the cut.
Building the brief prompt
The cron job fires an agentTurn payload containing your brief prompt. The prompt is the most important part of the setup. A vague prompt produces a vague brief. A specific prompt produces a specific brief. Invest time in getting the prompt right before automating it, because a bad prompt running automatically every morning is worse than no brief at all. A bad brief that arrives reliably every morning trains you to ignore it, which defeats the entire purpose of having a brief in the first place. The prompt is where you encode the discipline that keeps the brief useful.
Write a morning brief prompt for me to use in a cron job. The brief should: (1) Be delivered as exactly 5 bullet points, each a single sentence. (2) Cover these specific categories: [list your categories from the previous step]. (3) Pull information from these sources: [e.g., workspace files, memory recall, web search for specific topics, cron job run history]. (4) Use this format: each bullet starts with a bold category label, followed by the specific information. (5) End with a one-line “Today’s focus” that names the single most important thing I should prioritize. Write the complete prompt text that I will use as the agentTurn message in the cron job.
Test the prompt manually before scheduling it. Send the prompt as a regular chat message and evaluate the response. Is each bullet genuinely useful? Is any bullet so vague it could apply to any day? Is any source not being pulled correctly? Revise until the test run produces a brief you would actually use, then move to scheduling.
Run a test morning brief using this prompt: [paste your prompt]. Produce the brief as if it is tomorrow morning. After the brief, tell me: (1) Which bullets were genuinely specific and actionable? (2) Which bullets were generic or could apply to any day without modification? (3) What information sources did you pull from and which ones came back empty or unhelpful? I will use this feedback to refine the prompt before scheduling.
Testing the brief before scheduling
Before you commit to a daily automated brief, run at least three manual test runs on three different days. Each test run should be at the same time of day you plan to schedule the brief, using the exact prompt you intend to use in the cron job. The goal is to see how the brief changes based on actual daily context, not just a single snapshot. A prompt that works perfectly on Monday may produce generic filler on Tuesday when there is less activity. Testing across multiple days surfaces that pattern before you automate it.
Run a three-day test of my morning brief prompt. Use the prompt exactly as I will use it in the cron job. Run it now as if it is tomorrow morning, then again as if it is the day after tomorrow, then again as if it is the day after that. Show me the three briefs side by side. For each brief, tell me: (1) Which bullets were genuinely specific and actionable? (2) Which bullets were generic or could apply to any day? (3) Did any bullet category consistently come back empty? Based on this, recommend specific changes to the prompt to improve consistency across days.
After the three-day test, make the recommended changes and run one more test to confirm the improvements. Only after the final test produces a brief you would actually use should you schedule the cron job. The time spent testing upfront prevents the much larger time spent debugging a broken brief after it has been running for weeks and you have already trained yourself to ignore it.
Based on the three-day test results, update my morning brief prompt to fix the issues identified. The updated prompt should: [list the specific changes needed]. After updating, run one final test to confirm the improvements. Show me the final test brief and confirm that each bullet is specific, actionable, and not generic filler. Once confirmed, I am ready to schedule the cron job.
Scheduling the cron job
With a tested prompt, create the cron job. OpenClaw’s cron system handles the scheduling, fires the agentTurn, and routes the output to your chosen delivery channel. You set the time once and it runs every day from then on without any further action required.
Create a daily morning brief cron job. Configuration: (1) Schedule: every day at [your preferred time, e.g., 7:00 AM] in timezone [your timezone, e.g., America/New_York]. (2) Payload: agentTurn with this message: [paste your tested prompt]. (3) Delivery: announce to [your channel, e.g., Telegram chat ID 7930272159 or Discord]. (4) Session: isolated. (5) Name the job “Morning Brief”. Create this cron job and confirm the schedule is set correctly.
The cron expression for a 7:00 AM ET delivery is 0 7 * * * with timezone set to America/New_York. For a different time, adjust the hour. For multiple deliveries (morning and midday), create two separate cron jobs with different schedules and potentially different prompts for each time of day.
Confirm the morning brief cron job is correctly configured. List all cron jobs and show me the full configuration of the Morning Brief job: the schedule (with timezone), the exact agentTurn message, the delivery target, and whether it is enabled. Then trigger it manually right now so I can see the actual output before relying on it to fire automatically tomorrow morning.
Choosing the right delivery channel
The brief is only useful if you see it at the right time. Deliver it to wherever you actually look first in the morning, not wherever is easiest to configure. If you open Telegram before anything else, send it to Telegram. If you check Discord, send it to Discord. If you read email, route it to email. A brief that lands somewhere you check three hours later is not a morning brief.
Configure the morning brief delivery to [channel]. For Telegram: deliver to chat ID [your chat ID]. For Discord: deliver to user [your Discord user ID] or channel [channel ID]. For a different channel, tell me what channel integration is configured for my agent. Set the delivery mode to “announce” and the target to the correct recipient. Confirm the delivery is configured correctly by sending a test message to that target right now.
If you want the brief delivered to multiple channels, that is two cron jobs with the same prompt and different delivery targets. Keep both schedules identical so you receive the brief at the same time in both places rather than getting two out-of-sync versions at different times.
I want the morning brief delivered to both Telegram and Discord simultaneously. Create two separate cron jobs: one that delivers to Telegram at [time] and one that delivers to Discord at [time]. Both should use the same prompt. Name them “Morning Brief (Telegram)” and “Morning Brief (Discord)”. Confirm both are created with the same schedule and the same prompt content.
What to pull into the brief
The brief is only as good as the sources it pulls from. OpenClaw can query its own memory, read workspace files, search the web, check the run history of other cron jobs, and call external APIs if you have the right integrations. Each source adds latency to the brief generation. Keep sources to the minimum set that produces genuinely useful bullets and cut anything that consistently returns empty results or generic content. A source that returns the same generic placeholder three days in a row is not a source. It is noise. Remove it from the prompt and see if the brief becomes more useful without it.
Memory recall surfaces things the agent has stored from previous sessions: tasks that were left open, decisions that were made, items flagged for follow-up. This is one of the highest-value sources because it is personalized to your actual context and not available anywhere else. Memory recall is also the most reliable source. It does not depend on external APIs being up, does not require network connectivity beyond the local database, and returns results in milliseconds. If you only have one source in your brief, make it memory recall.
Workspace file reads pull from structured files you maintain: a task list, a project status file, a HEARTBEAT.md with monitoring items. These are reliable and fast because there is no network round-trip. If you maintain a daily priorities file or a current-sprint notes file, a workspace read is the right way to surface it in the brief.
Web search is useful for external context: breaking news in your industry, significant changes to tools or services you depend on, or scheduled events you should know about. Use it sparingly. Web search adds latency and the results need to be filtered before they add value. A search that returns only generic results every day is noise, not signal. The key to using web search effectively in a brief is to search for a specific, narrow query that either returns something actionable or returns nothing at all. A broad query like “AI news” will always return something, and that something will rarely be useful. A narrow query like “OpenClaw release notes March 2026” either returns a specific release announcement or returns nothing. That is the right kind of search for a brief.
Update my morning brief prompt to include these specific sources: (1) A memory recall for any items I flagged for follow-up in the last 7 days. (2) A read of [specific workspace file path] for current project status. (3) A web search for [specific topic, e.g., “OpenClaw updates” or your industry news]. For each source, add a corresponding bullet to the brief format. If any source returns no relevant results, that bullet should say “[Category]: Nothing to report today” rather than omitting the bullet entirely.
Refining the brief over the first two weeks
The brief you set up on day one will not be the brief you actually want by the end of the first week. Run it for three days before changing anything. After three days, you will have enough signal to identify the bullets that are consistently useful, the bullets that are consistently empty or generic, and any missing information that you wished had been in the brief each morning.
I have been running the morning brief for [number] days. Help me evaluate and improve it. Show me the cron job run history for the Morning Brief job. Based on the last [number] runs, which bullets have been consistently specific and actionable? Which bullets have been consistently empty, vague, or unchanged from day to day? Based on this, recommend specific changes to the prompt that would improve the signal-to-noise ratio.
Common refinements after the first week: cutting a bullet category that never has anything useful, tightening the format constraint to prevent multi-sentence bullets from creeping in, adding a source that was missing (you kept wishing the brief had mentioned something it did not), and adjusting the delivery time to better match when you actually read it versus when it fires.
Update the morning brief based on one week of running it. These are the changes I want to make: [list your specific changes, e.g., remove the third bullet, add a reminder of today’s calendar items, change delivery from 7AM to 6:30AM]. Update the cron job configuration and prompt to reflect these changes. Trigger a test run after updating so I can confirm the new brief format before tomorrow morning.
Advanced patterns for the brief
Once the basic brief is working reliably, several enhancements can increase its value without adding to the 30-second read time. These patterns are worth adding once you have tuned the core brief to deliver consistent signal.
Dynamic focus line. Instead of a fixed “Today’s focus” that is always the same type of statement, have the agent determine the single highest-priority item dynamically based on what it found in the other sources. If three sources all point to the same urgent item, the focus line should reflect that. The focus line should be the one thing you would act on even if you could not read the rest of the brief.
Day-of-week variants. Monday morning brief includes a weekly horizon scan. Friday morning brief includes a week-in-review bullet. The rest of the week uses the standard five-bullet format. This is two to three separate cron jobs with different prompts for different days of the week, using a cron expression that specifies the day (0 for Sunday, 1 for Monday, etc.).
Set up day-of-week variants for my morning brief. I want: (1) Monday brief at 7AM ET that adds a “This week” bullet summarizing key items for the week ahead. (2) Friday brief at 7AM ET that adds a “Last week” bullet with three highlights from the week’s memory. (3) Tuesday through Thursday uses the standard brief. Create the appropriate cron jobs with the right day-of-week constraints in the schedule. Show me the schedule expression for each.
Conditional escalation. Add a rule to the brief prompt: if any source returns an alert-level item (a service down, a deadline within 24 hours, a flagged urgent task), send an additional immediate notification rather than waiting for the scheduled brief time. This turns the brief from a passive daily digest into an active monitoring system for the items that cannot wait until morning.
Add a conditional escalation check to my morning brief. In the brief prompt, add a rule: after generating the standard five bullets, check whether any bullet represents an urgent item that should not wait until the scheduled delivery time. Define urgent as: [your criteria, e.g., a task with a deadline within 12 hours, an error rate above threshold, a critical service down]. If an urgent item is found, send an immediate Telegram notification with just that item before delivering the full brief at the scheduled time.
Example brief templates
The following templates are starting points for common use cases. Each is designed to produce exactly five bullets and one focus line. Copy the one closest to your situation, test it manually, and adjust the sources and categories to match your actual context before scheduling.
Template 1: Independent operator or freelancer. Covers active client work, outstanding tasks, and anything time-sensitive.
Produce a morning brief in exactly this format: five bullets, one sentence each, no explanation. Use these categories exactly: (1) OUTSTANDING: The highest-priority task carried over from yesterday that is not yet complete. (2) DEADLINE: The nearest upcoming deadline across all active projects and what it is for. (3) MESSAGES: Any unread messages, mentions, or replies that need a response today, summarized in one sentence. (4) BLOCKERS: Any active blocker that is preventing progress on something important. (5) CONTEXT: One piece of external context (API change, service status, relevant news) that affects my work today. End with: TODAY’S FOCUS: [single most critical action in one sentence]. If any category has nothing to report, write “[Category]: Nothing today.” Do not add any text before bullet 1 or after the focus line.
Template 2: Technical operator running automated systems. Covers system health, cron job status, and error conditions.
Produce a morning brief in exactly this format: five bullets, one sentence each. Use these categories: (1) SYSTEM: Current gateway status and whether any service restarted unexpectedly overnight. (2) CRONS: Status of the last run of each cron job. Note any failures or unexpected outputs. (3) MEMORY: Any items stored to memory in the last 24 hours that I should be aware of today. (4) ERRORS: Any tool call failures, API errors, or execution problems logged since yesterday’s brief. (5) QUEUE: Next pending item in any active task queue and its current status. End with: TODAY’S FOCUS: [single most critical maintenance or operational action]. If any category has nothing to report, write “[Category]: All clear.”
Template 3: Content creator or publisher. Covers content pipeline, publishing status, and audience metrics.
Produce a morning brief in exactly this format: five bullets, one sentence each. Categories: (1) PIPELINE: Next article or piece of content ready to publish and its current stage. (2) PUBLISHED: Most recent published piece and whether any post-publish tasks (cross-links, indexing check, social share) remain. (3) QUEUE: How many items are currently in the content queue at each status (PENDING, IN-PROGRESS, DONE). (4) METRICS: Any notable metric change from the last 24 hours (traffic spike, new subscriber count if available, engagement signal). (5) NEXT: The single next action needed to move the pipeline forward. End with: TODAY’S FOCUS: [the specific action that unblocks the most content output today].
Keeping the brief lean as you use it longer
The most predictable way a morning brief degrades over time is scope creep. It starts as five focused bullets. Over weeks, you add a sixth bullet for something that seemed important at the time. Then a seventh. The agent starts adding context after bullets because one bullet was ambiguous without explanation. Within a month, the 30-second brief is a four-minute read that you start skipping.
The defense against scope creep is a monthly brief audit. Read the last 30 days of briefs (or as many as you have saved) and count how many times each bullet category contained genuinely actionable information versus generic filler. Any category that comes back empty or useless more than half the time should be cut. Any bullet that consistently requires more than one sentence to be useful should either be cut or moved to a separate dedicated alert rather than the daily brief.
Run a brief audit. Check the cron run history for my Morning Brief job over the last 30 days. For each bullet category in my brief prompt, count: how many times did this category have genuinely specific, actionable content versus a “nothing to report” or generic placeholder? Rank the categories by usefulness. Recommend which categories to keep, which to cut, and whether any new category should be added based on what I have actually been doing in the last 30 days.
The second form of degradation is delivery time drift. You set the brief for 7 AM because that seemed like a reasonable morning time. But you do not actually read it until 9 AM when you sit down to work, by which point some of the time-sensitive items are already stale. Review the delivery time after the first month. The right time is 15 minutes before you actually start your day, not 15 minutes after you wake up. If you rarely check the brief at its delivery time, move it.
Update the Morning Brief cron job delivery time. Change it from [current time] to [new time] in timezone [your timezone]. Confirm the schedule is updated correctly. Then tell me what the next scheduled run time will be after this change.
Making the brief retrievable after the fact
The brief fires and delivers to your channel, but what if you need to review what was in yesterday’s brief, or you want to search across several weeks of briefs to see when a specific item first appeared? By default, cron job outputs are retained in the run history, but the history is limited and not easily searchable. Adding a workspace write to the brief means every brief gets archived in a format you can query later.
Update the morning brief prompt to also write its output to a file. After generating the five bullets and focus line, append the full brief to a file at: workspace/memory/briefs/YYYY-MM-DD.md (where YYYY-MM-DD is today’s date). Create the briefs directory if it does not exist. The file should contain: the date, the five bullets, and the focus line. Nothing else. This creates an archive I can query later. Update the cron job prompt to include this step and confirm it is added.
With a brief archive, you can ask the agent to pull context from past briefs when starting a new project, reviewing a month, or trying to remember when a specific blocker first appeared. The archive turns the brief from a disposable daily message into a queryable historical record of what was actually happening in your work each day.
Search my brief archive for context on [topic or project]. Read the files in workspace/memory/briefs/ and find every brief that mentioned [topic]. Show me the dates and the specific bullet text that referenced it. I want to understand how this item first appeared, how it changed over time, and what the last brief said about it.
Using the brief as an accountability tool
The morning brief becomes significantly more useful when it creates a loop with the previous day. A brief that only shows what is happening right now misses one of the most valuable things an agent with persistent memory can do: tell you what you said you were going to do yesterday, and whether you did it.
Adding a “carry-forward” bullet to the brief closes this loop. Each evening, the agent notes the one thing you committed to completing the next day. The next morning’s brief surfaces that commitment in the first bullet, before anything else. This is not a task list. It is a single commitment, one item, stated as specifically as possible. The brief holds you to it before the day starts.
Set up a daily commitment tracking system for my morning brief. (1) Create an evening cron job that fires at [time, e.g., 9PM] and asks: “What is the single most important thing you will complete tomorrow? Store it to memory with the tag ‘daily-commitment’ and the date.” (2) Update my morning brief prompt to recall the most recent memory tagged ‘daily-commitment’ and include it as bullet 1 under the label COMMITMENT. If no commitment was stored last night, the bullet should say “COMMITMENT: None set last night.” Update both the evening cron job and the morning brief prompt, then confirm both are configured.
Adapting the brief for a small team
If you run OpenClaw for a small team rather than for personal use, the same brief architecture works with one modification: the delivery target is a shared channel rather than a private message. Each team member reads the same brief in a shared Discord or Telegram channel. The brief covers shared context: project status, blockers affecting multiple people, upcoming deadlines that matter to everyone, and one team-level focus item for the day.
The content discipline requirement is higher for a team brief. A team brief that contains items only relevant to one person is noise for everyone else. Every bullet should be either relevant to everyone or a heads-up about something that affects how team members coordinate with each other. Personal task lists and individual status items belong in a personal brief, not the team one.
Set up a team morning brief. The brief should be delivered to [shared Discord channel ID or Telegram group ID] at [time]. The five bullets should cover: (1) PROJECT STATUS: One-sentence status on the single most active shared project. (2) BLOCKERS: Any shared blocker that affects more than one person. (3) TODAY’S HANDOFFS: Any items passing from one person’s domain to another today. (4) DECISIONS: Any decision made yesterday that affects the team’s work today. (5) FOCUS: The team’s single shared priority for today. Create the cron job targeting the shared channel and confirm it is set up correctly.
What not to put in the brief
As important as knowing what to include is knowing what to exclude. These items reliably degrade a brief when added, and most operators add them at some point. Knowing the failure modes in advance helps you design the brief so they do not creep in.
Weather. You already know the weather. Your phone’s home screen shows it. Adding weather to the brief fills a bullet with information that has zero incremental value and trains you to expect content-free bullets, which trains you to stop reading carefully.
News summaries. General news is not a morning brief item. News rarely changes what you do that day unless you are specifically tracking something. If you need to monitor a specific topic (an ongoing legal matter, a competitor’s product launch window, a regulatory deadline), that is a targeted search for one specific thing, not a general news summary. One targeted alert beats five generic headlines every time.
Things you already know. If a bullet is about something that has not changed in three days and you already know it, the brief is wasting a bullet confirming stale information. The brief should only surface things that changed since yesterday or that you might have missed. If nothing changed on a topic, that topic should not appear in the brief.
Long-form analysis. A brief is not a report. If a topic requires more than one sentence to convey, it belongs in a separate deeper report that you receive when you need it, not forced into a brief format where it either gets truncated or inflates the brief into something too long to read in 30 seconds.
Review my current morning brief prompt and identify any content categories that fall into the “do not include” patterns: weather, general news summaries, information that changes rarely or not at all, or anything that requires more than one sentence to be useful. For each item you identify, tell me whether to remove it entirely from the prompt or replace it with a more targeted alternative that would deliver actual signal. Then update the prompt to remove the identified items.
Frequently asked questions
The morning brief fires but I do not receive it. How do I debug the delivery?
Check the cron job run history first. If the job shows as completed successfully, the agentTurn ran but the delivery may have failed. Check the delivery configuration in the cron job: is the target channel ID correct? Is the channel integration active? Test the delivery independently by asking your agent to send a test message to the same target. If the test message delivers correctly but the brief does not, the issue is in the cron job delivery settings. If neither delivers, the channel integration itself has a problem that needs to be resolved separately.
Can the brief include information from external services I use, like GitHub or a project management tool?
Yes, if you have the relevant integrations configured or if you can query the service via web_fetch or a custom exec call. The most practical approach is to have a lightweight script run before the brief that pulls the relevant data (open PRs, ticket counts, sprint status) and writes it to a workspace file. The brief prompt then reads that file instead of making the external API call directly during brief generation. This decouples the brief from API rate limits and authentication complexity, and keeps the brief generation fast.
The brief is too long. The agent keeps adding explanation and context I did not ask for.
The prompt needs a harder format constraint. Add an explicit rule: “Each bullet must be a single sentence of no more than 20 words. Do not add explanation after the bullet. Do not add context unless it is part of the actionable information. If a bullet cannot be written in 20 words, it does not belong in this brief.” Explicit word limits are more effective than general instructions to be concise.
How do I pause the morning brief when I am on vacation?
Ask your agent to disable the cron job: “Disable the Morning Brief cron job until [date].” When you return, ask it to re-enable: “Re-enable the Morning Brief cron job.” You can also update the job to skip delivery if no actionable items are found, so that on quiet days the brief simply does not fire rather than delivering a list of empty bullets.
Can the brief include items from my calendar?
Only if you have a calendar integration configured. OpenClaw does not have native calendar access. If you have a calendar plugin or a script that exports today’s events to a workspace file, the brief prompt can read that file. The most common pattern is a lightweight script run by a separate cron job that writes today’s calendar events to a known file path each morning before the brief fires, then the brief prompt includes a read of that file.
The brief is running but I never look at it. How do I fix the habit problem?
Deliver it to the channel you open first, not the most convenient channel to configure. If you open your phone and check Telegram before anything else, send the brief to Telegram regardless of whether Discord is easier to set up. Then reduce the content until every single bullet is something you genuinely needed to know that day. If the brief consistently contains things you already knew or things that turned out not to matter, the content discipline problem will kill the reading habit. Fix the content first, then the habit follows.