Scheduled Reports in Slack with OpenClaw: Daily Standups, Weekly Digests

Reports Nobody Writes

Every team has reports they should be writing but aren't. The weekly project status update that stopped happening three sprints ago. The daily standup summary that used to get posted at 9am but now only appears when the team lead remembers. The monthly KPI roundup that takes someone two hours to assemble so it keeps getting pushed to "next week."

These reports die because they're tedious and repetitive. The information exists across tools; someone just has to pull it together and format it. That's exactly the kind of work an AI agent is built for. And if the agent can do it on a schedule without being asked, the reports never miss a beat again.

OpenClaw supports cron-triggered skills — automated tasks that run on a schedule and post results to Slack channels. Set it up once. It runs forever. Here's how to build the reports your team actually needs.

How Cron Triggers Work

If you've ever written a crontab entry, you know the format. If you haven't, it's simple: five fields that specify when a task runs.

┌───────────── minute (0-59)
│ ┌─────────── hour (0-23)
│ │ ┌───────── day of month (1-31)
│ │ │ ┌─────── month (1-12)
│ │ │ │ ┌───── day of week (0-6, 0 = Sunday)
│ │ │ │ │
* * * * *

Some examples:

• 0 9 * * 1-5 — 9am, Monday through Friday
• 0 17 * * 5 — 5pm every Friday
• 0 8 1 * * — 8am on the first of every month
• */30 * * * * — Every 30 minutes

In your OpenClaw skill file, you set the trigger like this:

trigger:
  type: cron
  schedule: "0 9 * * 1-5"
  channel: "#team-updates"
  timezone: "America/New_York"

The timezone field matters. Without it, the schedule runs in UTC, which means your 9am report might post at 4am local time. Always set the timezone to match your team's primary location. For distributed teams, you can create multiple versions of the same skill with different timezones.

Daily Standup Summary

The async standup is the most common scheduled report, and for good reason. Synchronous standups take 15-30 minutes of everyone's time. Async standups let people post updates when it suits them, and the agent compiles everything into a single summary.

Option 1: Summarize Existing Updates

If your team already posts standup updates in a channel throughout the day, the agent can just summarize them:

---
name: daily_standup_digest
trigger:
  type: cron
  schedule: "0 17 * * 1-5"
  channel: "#engineering"
  timezone: "America/Chicago"
tools:
  - slack
---

# Daily Standup Digest

Read all messages posted in #engineering-standup today.

For each person who posted:
- Extract what they completed today
- Extract what they plan to work on tomorrow
- Extract any blockers

Create a summary formatted as:

**Standup Summary — [today's date]**

For each person:
- ✅ Completed: [items]
- 🔜 Next: [items]
- 🚫 Blockers: [items, if any]

**Team-wide blockers:** [list any blockers that affect multiple people]

**Who didn't post:** [list team members with no update today]

Post this summary to #engineering as a top-level message.

Option 2: Pull Data from Tools

Instead of relying on people to write updates, pull the data from where the work actually happens:

---
name: automated_standup
trigger:
  type: cron
  schedule: "0 9 * * 1-5"
  channel: "#engineering"
  timezone: "America/New_York"
tools:
  - github
  - linear
  - slack
---

# Automated Daily Standup

Generate a standup report by pulling activity from the last 24 hours.

## Data Sources

1. **GitHub:** PRs opened, PRs merged, PRs reviewed — for repos:
   main-app, api-service, mobile-app
2. **Linear:** Tickets moved to "In Progress," tickets moved to "Done,"
   new tickets created
3. **Slack:** Any messages in #engineering-blockers posted yesterday

## Format

**Daily Activity — [date]**

**Shipped:**
- [list merged PRs with author and linked Linear ticket]

**In Review:**
- [list open PRs awaiting review, with reviewer and age]

**In Progress:**
- [list Linear tickets currently "In Progress" with assignee]

**Blockers:**
- [anything from #engineering-blockers]

Post to #engineering.

This version is better because it doesn't require anyone to write an update. The data is already in GitHub and Linear. The agent just reads it and formats it. Zero effort from the team, accurate every time.

Weekly Project Digest

The Friday afternoon project summary. Every manager wants it. Nobody wants to write it.

---
name: weekly_project_digest
trigger:
  type: cron
  schedule: "0 16 * * 5"
  channel: "#project-updates"
  timezone: "America/Los_Angeles"
tools:
  - linear
  - github
  - notion
  - slack
---

# Weekly Project Digest

Generate a project digest covering Monday through Friday of this week.

## For each active project in Linear:

1. Tickets completed this week (count and list)
2. Tickets still in progress
3. Sprint progress (% complete vs planned)
4. Any tickets that were added mid-sprint (scope creep indicator)

## GitHub Activity:
- Total PRs merged across all repos
- Average time from PR open to merge
- Any PRs open longer than 3 days

## Key Decisions:
- Scan #engineering, #product, and #design channels for messages
  that received 3+ reactions (indicates agreement/attention)
- Summarize the top 3-5 notable decisions or discussions

## Format:
Post as a structured summary. Keep it under 500 words.
Link to specific Linear tickets and GitHub PRs where relevant.
End with "Blockers going into next week:" section.

This report takes a human 30-45 minutes to assemble. The agent does it in seconds. And it's more accurate because it pulls from source systems rather than relying on someone's memory of what happened this week.

Sprint Reports

At the end of each sprint, generate a retrospective data summary:

---
name: sprint_report
trigger:
  type: cron
  schedule: "0 10 * * 1"  # Monday morning, start of new sprint
  channel: "#engineering-leads"
  timezone: "America/New_York"
tools:
  - linear
  - github
---

# Sprint Close Report

Generate a report for the sprint that ended last Friday.

## Metrics:
- Planned points vs completed points
- Completion rate (%)
- Tickets carried over to next sprint (list with reasons if available)
- Bugs found vs bugs fixed
- Average ticket cycle time (time from "In Progress" to "Done")

## Velocity Trend:
- Compare this sprint's velocity to the 4-sprint rolling average
- Note if velocity is trending up, down, or stable

## Highlights:
- Largest tickets completed (by point value)
- Any tickets that took significantly longer than estimated

## Carry-Over Analysis:
- List tickets not completed with current status
- If a ticket has been carried over 2+ sprints, flag it

Post to #engineering-leads with a thread containing the detailed
ticket-by-ticket breakdown.

GitHub Summary Reports

For engineering managers who want visibility into repository activity:

---
name: github_weekly
trigger:
  type: cron
  schedule: "0 9 * * 1"
  channel: "#eng-metrics"
tools:
  - github
---

# Weekly GitHub Summary

Analyze GitHub activity across all connected repositories for the past 7 days.

Report:
- **PRs merged:** Count, average size (lines changed), average review time
- **PRs opened but not yet merged:** Count, list with age and assignee
- **Top contributors:** Top 5 by PRs merged
- **Code review participation:** Who reviewed the most PRs
- **Issues opened vs closed:** Net change
- **Release activity:** Any new tags or releases

Flag anything unusual: a PR with 2000+ lines changed, a review that
took longer than 5 days, an issue that's been open 30+ days with
no activity.

KPI Dashboards

Not every team has a fancy BI tool. And even teams that do often want key numbers posted to Slack where everyone sees them.

---
name: monthly_kpi
trigger:
  type: cron
  schedule: "0 8 1 * *"  # First of every month at 8am
  channel: "#leadership"
tools:
  - salesforce
  - stripe
  - google_analytics
---

# Monthly KPI Report

Pull metrics for the previous calendar month.

## Revenue (Stripe):
- MRR at month end
- MRR change vs previous month (absolute and %)
- New MRR (from new customers)
- Churned MRR
- Net revenue retention rate

## Sales (Salesforce):
- New opportunities created
- Opportunities closed-won (count and value)
- Win rate
- Average deal size
- Pipeline coverage ratio (pipeline value / quota)

## Product (Google Analytics):
- Monthly active users
- New signups
- Activation rate (% of signups completing onboarding)
- Top 5 pages by traffic

Format as a clean, scannable summary. Use directional arrows
(↑ ↓ →) to indicate trends vs previous month.
Bold any metric that changed more than 10% in either direction.

Tips for Better Scheduled Reports

• Less is more. A 10-line summary that people actually read beats a 50-line report everyone scrolls past. Tell the agent to be concise.
• Use threads for detail. Post the summary to the channel, put the detailed breakdown in a thread reply. People who want more can click in.
• Include links. Every metric should link back to its source. "MRR: $142K (↑ 8%)" should link to the Stripe dashboard.
• Set the right timezone. Obvious but frequently forgotten. A report that posts at 2am helps nobody.
• Don't over-schedule. A daily KPI report is noise. A weekly one is useful. Match the cadence to how often the information actually changes.

For more on setting up these workflows, see our guide on time-based OpenClaw skills and the recurring reports setup guide.

The Compound Effect

One scheduled report saves 30 minutes a week. Ten of them save 5 hours. But the real value isn't time saved — it's consistency. Reports that run on cron never forget. They never have an off week. They never skip a Friday because someone's on vacation. The information flows, every time, on time.

Teams that adopt scheduled reporting through OpenClaw consistently tell us the same thing: they didn't realize how much institutional knowledge was trapped in manual processes until the bot started surfacing it automatically. The data was always there. It just needed someone (or something) to reliably pull it together.

That's what cron is for. Set it and move on to the work that actually requires your brain.