Replacing your morning routine with a cron job: news, inbox, priorities, delivered before you sit down

A morning routine that runs itself: news brief, inbox triage, priority list, weather, calendar summary. Delivered to your phone before you sit down. This guide builds the full morning brief stack with the exact cron configurations, prompts, and model routing to keep it under $0.05/day.

Why automate your morning routine

Most people’s morning routine is reactive. Open phone, check news (anxiety). Open email, triage chaos. Open calendar, remember the meeting you forgot. Check Slack. Feel overwhelmed before 9 AM. Start work from behind.

A morning brief inverts this. Before you sit down, a set of crons has already: read the news and pulled the three things that matter to your work, triaged your inbox and identified what needs a reply today, pulled your calendar and flagged any conflicts or prep needed, checked your task list and suggested the first three things to do. All of this arrives as a single Telegram message at 7:30 AM. You read it, you know what the day looks like, you start from context instead of chaos.

The brief doesn’t replace judgment. It replaces the 20-30 minutes of unfocused scanning that precedes judgment every morning. That’s the time it recovers.

The architecture: chained crons

The morning brief is built from four crons that run in sequence:

1. 6:00 AM: Research cron: pulls news, checks specified sources, writes a raw summary to a temp file
2. 6:30 AM: Inbox cron: reads email, classifies by priority, writes triage summary to a temp file
3. 7:00 AM: Priority cron: reads your task list and calendar, writes a suggested priority list to a temp file
4. 7:30 AM: Assembly cron: reads all three temp files, assembles the final brief, sends to Telegram

Each cron writes output that the next reads. The assembly cron sees all three inputs and formats them into the final message. If any upstream cron fails, the assembly cron still runs and notes which section is missing. You always get something, even when one piece breaks.

Stage 1: The news cron

The news cron runs at 6 AM and reads your specified sources. It doesn’t send anything. It writes a structured summary to a temp file that the assembly cron will read at 7:30.

Create a cron job that runs at 6:00 AM daily (convert to UTC for my timezone). Task: use the web_search tool to search for news on these topics: [your topics, e.g., “AI industry news”, “your industry”, “your company name”]. Run one search per topic. For each search, extract the 2-3 most relevant results published in the last 24 hours. Write a structured summary to /home/node/.openclaw/workspace/tmp/morning-news.md in this format:

## Morning News [date]
### [Topic 1]
– [Headline]: [one sentence summary] ([source])
### [Topic 2]
– [Headline]: [one sentence summary] ([source])

If a search returns nothing new in the last 24 hours, write “Nothing new” for that section. Use ollama/phi4:latest. Do not send a Telegram message.

Choosing your news topics

The most useful morning brief topics are specific, not broad. “Technology news” returns too much and too little of what actually matters. Better topics for most professionals:

• Your specific industry vertical (“enterprise SaaS security” instead of “tech news”)
• Your company’s name and key competitors (monitor what people are saying)
• Key technology topics you track professionally (specific tools, frameworks, platforms)
• Local business news if relevant to your work
• One or two broader topics you want to stay aware of personally

Three to five topics is the sweet spot. More than five and the brief becomes unreadable; fewer than three and it may not be worth the automation.

Stage 2: The inbox cron

The inbox cron reads your email (if connected) or your Telegram message log, classifies what came in overnight, and writes a priority-ordered triage summary. The goal is not to draft replies (that’s the AI clone’s job). The goal is to tell you, in 30 seconds, what actually needs your attention today.

Create a cron job that runs at 6:30 AM daily. Task: read messages or emails received in the last 12 hours. Classify each as: URGENT (needs same-day response, time-sensitive), IMPORTANT (needs response this week, not urgent), or FYI (no response needed). Write the results to /home/node/.openclaw/workspace/tmp/morning-inbox.md in this format:

## Morning Inbox [date]
### URGENT ([count])
– [sender]: [subject/topic in one line]
### IMPORTANT ([count])
– [sender]: [subject/topic in one line]
### FYI ([count], skipping details)

Use these classification signals: URGENT if the sender is [list key people], if there’s a deadline mentioned, or if the word “urgent” or “ASAP” appears. IMPORTANT if it’s a client, a colleague on a current project, or contains a question that needs an answer. FYI everything else. Use ollama/phi4:latest.

Calibrating the urgency signals

The classification is only as good as the signals you give it. Before running this live, spend five minutes on your inbox and write down: who always gets URGENT status regardless of content? What phrases signal urgency to you? What topics are always important? Feed those specifics into the cron instruction and the classification will be accurate from day one instead of requiring calibration.

Stage 3: The priority cron

The priority cron reads your task list and calendar and produces three suggested priorities for the day. This is the cron most people are skeptical about until they see it work. The agent isn’t making decisions for you. It’s reading context you’ve already written and surfacing what’s most time-sensitive.

Create a cron job that runs at 7:00 AM daily. Task: read /home/node/.openclaw/workspace/tasks/TASKS.md (my task list) and /home/node/.openclaw/workspace/tasks/CALENDAR.md (my upcoming events). Identify: (1) any tasks due today or overdue, (2) any calendar events today that require preparation, (3) the three highest-priority open tasks based on deadlines and dependencies. Write to /home/node/.openclaw/workspace/tmp/morning-priorities.md in this format:

## Morning Priorities [date]
### Due Today or Overdue
– [task]
### Prep Needed for Today’s Events
– [event at time]: [what prep is needed]
### Top 3 Open Priorities
1. [task]
2. [task]
3. [task]

If the files don’t exist or are empty, write “No task data available.” Use ollama/phi4:latest.

Keeping your task and calendar files current

This cron is only as useful as the files it reads. If you don’t maintain TASKS.md and CALENDAR.md, the priority cron produces nothing useful. The simplest maintenance pattern: at the end of each work day, spend three minutes updating both files. The morning brief is the payoff for that three minutes of upkeep.

Create a cron that runs at 5:30 PM on weekdays. Send me a Telegram message: “End of day: update TASKS.md with today’s completions and new tasks. Update CALENDAR.md with any new events added today. Reply ‘done’ when complete.” This prompts the update so the morning brief has current data.

Stage 4: The assembly cron

The assembly cron runs last and turns the three input files into the final Telegram message. This is the only cron that uses a paid model, because the output goes directly to you and needs to be readable and well-formatted.

Create a cron job that runs at 7:30 AM daily. Task: read three files: /home/node/.openclaw/workspace/tmp/morning-news.md, /home/node/.openclaw/workspace/tmp/morning-inbox.md, and /home/node/.openclaw/workspace/tmp/morning-priorities.md. If any file is missing or empty, note that section as “unavailable” in the final brief. Assemble a Telegram message with this exact structure:

Good morning. Here’s your brief for [day, date].

NEWS
[2-3 bullet points from morning-news.md, most relevant first]

INBOX
[urgent count and top items from morning-inbox.md]

PRIORITIES
[top 3 priorities from morning-priorities.md]

Keep the entire message under 300 words. Use deepseek/deepseek-chat for assembly. Send to my Telegram immediately after composing.

Using deepseek-chat only for the assembly step keeps costs low: three local model runs (free) and one API model run per day (~$0.01-0.02). Total monthly cost: roughly $0.30-0.60. For the value of a structured morning brief every day, this is the cheapest productivity investment available.

Testing the full stack

Before waiting for 7:30 AM, test each stage manually in order:

Run the morning brief stack manually right now in sequence: first run the news cron, then the inbox cron, then the priority cron, then the assembly cron. Show me the output of each stage. For the assembly cron, actually send the Telegram message so I can see how it looks on my phone.

The manual run tells you three things: whether each cron produces sensible output, whether the assembly cron reads and combines all three inputs correctly, and what the final brief looks like at real size. Most people adjust the brief format after seeing it the first time.

Customizing the brief format

The format above is a starting point. Common customizations:

Adding weather

Update the news cron to also fetch the current weather for [your city] using the wttr.in API: curl wttr.in/[city]?format=3. Add the result to morning-news.md as the first line before the news sections.

Adding a motivational or focus prompt

Update the assembly cron to end every brief with one sentence from this list, cycling through them: [paste 10-20 short focus prompts, reminders, or principles you find useful]. Pick the next one in sequence based on the day of the week.

Day-specific customization

Update the assembly cron with day-specific additions: on Mondays, include a one-sentence summary of the week’s key events from CALENDAR.md. On Fridays, include a “week in review” line based on completed tasks from TASKS.md. On weekends, skip the INBOX section and replace PRIORITIES with “Weekend. No work priorities.” Detect the current day and apply the appropriate variation.

Handling the brief when you’re traveling or on vacation

A morning brief that fires while you’re on a plane or at the beach is just noise. Add a pause mechanism:

Create a file at /home/node/.openclaw/workspace/tasks/PAUSE.md. When this file exists and contains “brief:paused”, the assembly cron should skip sending the brief and instead send one short message: “Brief paused.” Update the assembly cron to check for this file before assembling. To pause the brief, I’ll tell you “pause the brief”; to resume, I’ll say “resume the brief”. Create the file now with no content so the system is ready.

SOTA model context for morning briefs (March 2026)

As of March 2026, the local model stack (phi4:latest for reading and classification, deepseek-chat for assembly) is the right choice for this architecture. Three notes on current model capabilities that affect brief quality:

Web search accuracy

phi4:latest uses the web_search tool to find news, but the quality of results depends on how the search queries are constructed. The model sometimes constructs overly broad queries. If your news section consistently returns irrelevant results, make the topic descriptions more specific in the cron instruction. “Recent developments in enterprise AI security tools” produces better results than “AI security news.”

Email classification accuracy

At 14B parameters, phi4 is accurate at classification when the signals are explicit. The more specific your urgency signals (sender names, keywords, topic patterns), the more accurate the classification. Vague signals like “important-looking emails” produce inconsistent results. Specific signals like “any email from [client name] or containing the word ‘deadline’” produce reliable ones.

Assembly quality

deepseek-chat produces clean, readable assembly output and follows formatting instructions reliably. If the brief format looks off, the issue is usually in the input files (one of the three upstream crons produced garbled output) rather than the assembly step. Debug upstream first before adjusting the assembly prompt.

Real morning briefs from actual operators

These are anonymized examples of morning brief configurations that OpenClaw operators are running as of March 2026. Seeing what others have built makes it easier to understand what’s possible.

The freelance designer’s brief

A freelance UX designer uses a five-section brief: client project updates (reads a shared Notion page via API), new job board postings matching specific criteria, design industry news from two RSS feeds, her task list with deadlines highlighted, and a one-line weather report. The whole thing runs on phi4 except the assembly step, costing under $0.50/month. She reads it on her phone before getting out of bed and arrives at her desk knowing exactly what the day needs.

The startup founder’s brief

A startup founder has a brief with seven sections: overnight Slack highlights from three key channels (summarized by phi4), customer support ticket volume (via API call to their helpdesk), competitor news searches on four company names, fundraising-relevant news (searches around their sector), a weather check for the city where they have an in-person meeting scheduled, their own priority list from a TASKS.md file, and the assembly step which produces a brief he’s trained himself to read in under two minutes. Cost: around $0.03/day using deepseek-chat for assembly only.

The data professional’s brief

A data operations professional tracks pipeline health, not news. Her morning brief reads three status files that automated health checks write overnight (API status, database row counts, error log summaries), classifies any anomalies, and sends an alert-style brief: “3 pipelines nominal, 1 anomaly: [detail].” If everything is green, the brief is two lines. If something is off, it’s five lines with the relevant details. She reads it once, knows whether she needs to act before standup, and moves on. Cost: $0.00 (all phi4, nothing in the brief requires generation quality).

The researcher’s brief

A researcher monitors two arXiv feeds, a set of specific author pages, and three academic blogs. The morning cron reads these sources via web_fetch, extracts anything published in the last 24 hours, scores each item for relevance to their current project (explicit criteria in the instruction), and sends the top three results with abstracts. On most days the brief has nothing (research publishes infrequently). On high-activity days it has four or five entries. The researcher checks it every morning and reads maybe 25% of them. The value is in the ones they would have missed if not for the brief.

Advanced brief patterns

The adaptive brief: different sections on different days

A static brief gets stale after a few weeks. Adding day-specific logic keeps it relevant:

Update the assembly cron with day-specific logic. Monday: include a full week preview from CALENDAR.md (“this week you have: [events]”). Tuesday-Thursday: standard brief. Friday: add a week-in-review section based on completed items in TASKS.md (“this week you completed: [list]”) and a “leaving for the weekend” check (“open items that will wait until Monday: [list]”). Saturday and Sunday: brief is optional. Check PAUSE.md for a “weekend:brief” flag and only run if it’s set. Show me the updated assembly cron instruction.

The escalating brief: quiet days vs. active days

On quiet days, a long brief wastes your time. On active days, a short brief misses things. An escalating brief adjusts its length based on how much is actually happening:

Update the assembly cron. Before assembling, count: total URGENT inbox items, total tasks due today, and total calendar events today. If the total is 0-2, produce a “quiet day” brief: three sentences maximum, just the headlines. If the total is 3-6, produce a “normal day” brief: the standard format. If the total is 7 or more, produce an “active day” brief: full detail on every urgent item, all same-day tasks listed, all events with their prep requirements. Label the brief with its type at the top so I know how much to expect.

The comparative brief: today vs. yesterday

Tracking changes from day to day surfaces patterns the single-day view misses:

Update the assembly cron to save a snapshot of today’s priorities and inbox count to /home/node/.openclaw/workspace/tmp/brief-yesterday.md after sending. The next morning, before assembling the brief, read brief-yesterday.md and compare: did the inbox URGENT count go up or down? Did yesterday’s top 3 priorities get completed (check TASKS.md)? Add a one-line delta at the top of the brief: “Inbox: 3 URGENT (same as yesterday / +2 from yesterday / -1 from yesterday). Yesterday’s priorities: 2/3 completed.”

Connecting additional data sources to your brief

RSS feeds and blogs

Many data sources publish RSS feeds that are easier to parse than web pages. The news cron can read these directly:

Update the news cron to also fetch these RSS feeds using curl: [list your RSS feed URLs]. Parse the XML response to extract entries published in the last 24 hours. For each entry, extract the title and description. Add the results to morning-news.md under a “Blogs and Feeds” section. Score each entry by relevance to these topics: [your topics]. Include only entries scoring 6 or above. Use ollama/phi4:latest.

GitHub activity monitoring

Developers tracking specific repositories or organizations get useful signal from GitHub’s API. The morning brief can include a section on overnight commits, opened issues, or new releases:

Add a GitHub monitoring step to the news cron. Use curl to call the GitHub API for these repositories: [list repos]. For each, check commits, issues, and releases from the last 24 hours. Write a summary to morning-news.md under “GitHub Activity”: repo name, event type, and a one-line description. Authenticate with this token: [your GitHub token]. Use ollama/phi4:latest to parse and summarize.

API-based data: weather, stock prices, crypto

Public APIs provide structured data that fits cleanly into a brief. Weather is the most common, but stock prices, cryptocurrency values, and other financial data work the same way:

Add a weather step to the news cron. Use curl to fetch weather data from wttr.in for [your city]. Parse the response for current temperature and conditions. Add to morning-news.md as the first line: “Weather: [temp]°F, [conditions].” If you track specific stocks or cryptocurrencies, add a second curl call to a financial API (Alpha Vantage, CoinGecko, etc.) and include the overnight change for each. Keep each line under 10 words.

Custom APIs and internal tools

If your company has internal APIs (project management, CRM, support ticket systems), the morning brief can pull data from them. The pattern is the same: curl with authentication, parse the JSON response, extract the relevant fields, write to the temp file:

Add an internal API step to the news cron. Call this endpoint: [your internal API endpoint] with this authentication header: [your auth]. Parse the JSON response for these fields: [list fields]. Write a summary to morning-news.md under “Internal Updates”: one line per significant change. Use ollama/phi4:latest for parsing.

Integration with other productivity systems

The morning brief doesn’t exist in isolation. It works best when connected to the other systems you use. Here’s how to wire it into common productivity setups:

Notion integration

If you use Notion for task management, the priority cron can read from a Notion database via the API instead of TASKS.md. The pattern is the same: authenticate, query, parse, write to temp file:

Update the priority cron to read tasks from Notion instead of TASKS.md. Use curl to query the Notion API for this database: [database ID]. Filter for tasks due today or overdue. Parse the JSON response, extract task titles and due dates, write to morning-priorities.md. Authenticate with this Notion integration token: [your token]. Use ollama/phi4:latest for parsing.

Google Calendar integration

Instead of maintaining CALENDAR.md manually, connect directly to Google Calendar via the API. The priority cron can fetch today’s events and any that need preparation:

Update the priority cron to read events from Google Calendar. Use curl with OAuth to fetch events for today from [calendar ID]. Parse the JSON, extract event titles, times, and descriptions. Write to morning-priorities.md under “Today’s Events”. Include any events that have the word “prep” in the description or title as needing preparation. Use ollama/phi4:latest.

Slack integration

For teams that use Slack, the inbox cron can read from specific Slack channels instead of email. The classification logic works the same way:

Update the inbox cron to read messages from these Slack channels: [channel names]. Use the Slack API to fetch messages from the last 12 hours. Classify each message as URGENT, IMPORTANT, or FYI using the same signals as email classification. Write to morning-inbox.md with sender name and message preview. Authenticate with this Slack bot token: [your token].

Trello/Asana/Jira integration

Project management tools are natural data sources for the priority cron. Each has an API that returns tasks assigned to you, their due dates, and status:

Update the priority cron to read tasks from [Trello/Asana/Jira]. Use curl to query the API for tasks assigned to me with due dates today or overdue. Parse the response, extract task names and project context, write to morning-priorities.md. Authenticate with [your API key]. Use ollama/phi4:latest for parsing.

The evolution of your brief over time

A morning brief that starts simple can grow into a comprehensive dashboard. Here’s the typical evolution path operators follow:

Month 1: The basics

News, inbox, priorities. Three sections, delivered at 7:30 AM. You’re learning what works and what doesn’t. Cost: $0.30-0.60/month.

Month 2-3: Adding data sources

Weather, RSS feeds, internal APIs. The brief grows to 4-5 sections. You start removing sections that don’t provide value. Cost: still under $1/month.

Month 4-6: Integration with other tools

Notion, Google Calendar, Slack replace manual files. The brief becomes more accurate because it’s reading live data instead of manually maintained files. Cost: same.

Month 7-12: Adaptive logic

Day-specific sections, escalation based on workload, comparative analysis. The brief adjusts to your context instead of being static. Cost: same.

Year 2+: Multiple briefs

Some operators add a second brief for specific contexts: a weekend brief with different sections, a travel brief that focuses on different data, a project-specific brief that runs only during certain engagements. The core morning brief remains, but specialized variants appear for specific situations.

What to do when you outgrow the morning brief

Eventually, the morning brief may become too much for a single Telegram message. When that happens, you have two options:

Option 1: Split into multiple messages

Keep the same crons but change the assembly cron to send three separate Telegram messages: one for news, one for inbox, one for priorities. Each gets its own notification, and you can read them in whatever order makes sense for your morning.

Update the assembly cron to send three separate Telegram messages instead of one. Message 1: “Morning News” with just the news section. Message 2: “Morning Inbox” with just the inbox section. Message 3: “Morning Priorities” with just the priorities section. Space them 30 seconds apart so they arrive as separate notifications.

Option 2: Move to a dashboard

Instead of sending to Telegram, write the assembled brief to a Markdown file and serve it via a simple web page. The morning cron updates the page, and you bookmark it to read on your computer. This works better for longer briefs with more data.

Update the assembly cron to write the brief to /home/node/.openclaw/workspace/brief/index.html instead of sending to Telegram. Format it as a clean HTML page with sections. Also send a Telegram message with just the link: “Morning brief ready: [URL]”. Create a simple HTTP server to serve the file if one doesn’t exist.

Cost breakdown (March 2026 pricing)

• News cron (phi4, daily): $0.00
• Inbox cron (phi4, daily): $0.00
• Priority cron (phi4, daily): $0.00
• Assembly cron (deepseek-chat, daily): ~$0.01-0.02/day
• End-of-day prompt cron (phi4, weekdays): $0.00
• Total monthly cost: $0.30-0.60/month

At that cost, every single morning brief pays for itself if it saves you five minutes. It consistently saves 20-30. The ROI on this automation is unusually clear: a fixed small cost for a fixed large daily time recovery.

The cost stays the same regardless of how many data sources you add or how complex the brief becomes, because only the assembly step uses a paid model. The reading, classification, and parsing steps all use phi4:latest at $0.00. This is why the morning brief is one of the highest-ROI automations you can build with OpenClaw.

Getting started: the minimum viable morning brief

If the full four-cron stack feels like too much to start with, build a minimum viable brief first. This is a single cron that does one thing well, delivered every morning. Once that works, add the other pieces.

The best single-cron starting point is the priority cron alone. It reads your task list and calendar and sends a simple Telegram message with what’s due today. No news, no inbox, just priorities. This takes 15 minutes to set up and provides immediate value:

Create a single cron that runs at 7:30 AM daily. Task: read /home/node/.openclaw/workspace/tasks/TASKS.md and /home/node/.openclaw/workspace/tasks/CALENDAR.md. Identify tasks due today and calendar events today. Send a Telegram message with this format: “Good morning. Today: [count] tasks due, [count] events. Top priority: [most urgent task]. First event: [next event time and title].” Use ollama/phi4:latest.

Run this for a week. When you’re comfortable with it working reliably, add the news cron. Then the inbox cron. Then split them into separate crons with the assembly step. Building incrementally reduces the risk of something breaking and makes each new piece easier to debug.

Common pitfalls and how to avoid them

These are the mistakes most people make when building their first morning brief. Knowing them upfront saves time:

1. Building all four crons at once. Start with one. Get it working. Then add the next. Debugging four interconnected crons when you’re not sure which one is broken is much harder than debugging one.
2. Not testing manually first. Run each cron instruction as a regular message before turning it into a scheduled task. If it doesn’t work in conversation, it won’t work in a cron.
3. Using vague classification signals. “Important emails” is vague. “Emails from [list of people] or containing [list of keywords]” is specific. Specific signals produce consistent results.
4. Forgetting timezone conversion. Your local 7:30 AM is not UTC 7:30 AM. Confirm the UTC equivalent with your agent before saving the cron.
5. Not adding failure notifications. A cron that fails silently is worse than no cron at all. Add Telegram failure alerts to every cron before you consider it done.
6. Building for perfection instead of utility. A brief that’s 80% accurate and arrives every day is more useful than a brief that’s 95% accurate but breaks once a week. Ship the 80% version, then improve it.

What to do when the brief is wrong

The brief will get things wrong at first. The news will occasionally include irrelevant results. The inbox classification will misfire on edge cases. The priorities will sometimes miss something obvious. This is normal and expected. The calibration process:

1. Note what was wrong. Specifically: which section, what the wrong output was, what the right output would have been.
2. Identify which cron produced the wrong output. Was it the news cron’s search query? The inbox classification signal? The priority ranking logic?
3. Update the specific instruction for that cron. Add the missing signal or tighten the query. Don’t rewrite the whole instruction if one sentence is the problem.
4. Run the cron manually again to confirm the fix works before waiting for the next morning.

Most briefs stabilize within two weeks of daily use. After that, the only adjustments are when your professional context changes (new clients, new projects, new topics to track) and when you want to add new sections.

Cost breakdown (March 2026 pricing)

Web search accuracy

phi4:latest uses the web_search tool to find news, but the quality of results depends on how the search queries are constructed. The model sometimes constructs overly broad queries. If your news section consistently returns irrelevant results, make the topic descriptions more specific in the cron instruction. “Recent developments in enterprise AI security tools” produces better results than “AI security news.”

Email classification accuracy

At 14B parameters, phi4 is accurate at classification when the signals are explicit. The more specific your urgency signals (sender names, keywords, topic patterns), the more accurate the classification. Vague signals like “important-looking emails” produce inconsistent results. Specific signals like “any email from [client name] or containing the word ‘deadline’” produce reliable ones.

Assembly quality

deepseek-chat produces clean, readable assembly output and follows formatting instructions reliably. If the brief format looks off, the issue is usually in the input files (one of the three upstream crons produced garbled output) rather than the assembly step. Debug upstream first before adjusting the assembly prompt.

Frequently asked questions

What if I don’t have email connected to OpenClaw?

The inbox cron can read from any message source OpenClaw is connected to: Telegram, Discord, or a watched file. If email isn’t connected, skip the inbox cron and replace it with a Telegram or Discord message triage cron that reads your connected channel’s recent messages. The structure is identical; only the source changes.

Can I add a section for specific websites I want to monitor?

Yes. Add a separate stage before the assembly cron that visits your specified URLs using web_fetch, extracts new content, and writes it to a fourth temp file. Update the assembly cron to include that file in the brief. The cost is still $0.00 for the monitoring stage if you use phi4:latest.

How long does the full stack take to run?

With 30-minute gaps between stages and phi4 running locally, the full stack from 6 AM to 7:30 AM takes about 90 minutes of elapsed time but only 3-8 minutes of actual processing time (the rest is waiting for the next cron to fire). The assembly step using deepseek-chat adds 10-30 seconds. Your brief arrives at 7:30 AM regardless of how long each step takes.

What if one of the upstream crons fails?

The assembly cron checks whether each input file exists and has content. If a file is missing or empty, the brief notes that section as unavailable and assembles from what’s there. You still get a partial brief rather than nothing. The failure also triggers the standard failure notification configured in the upstream cron.

Can I get the brief via Discord instead of Telegram?

Yes. Update the assembly cron instruction: replace “send to Telegram” with “send to my Discord channel.” The message content is identical; only the channel changes. If you want it in both places, add a second send step in the assembly cron.

How do I add a section for my investment portfolio or financial data?

Add a pre-assembly cron that calls a financial API (most have free tiers for basic data) using curl, extracts the data you want to track, and writes it to a temp file. Include that file in the assembly cron’s inputs. The cost depends on the API; the agent-side processing uses phi4 for free. Most financial data APIs (Alpha Vantage, Yahoo Finance via yfinance wrapper, etc.) are accessible via curl without authentication for basic price data.

Keep Reading: