OpenClaw Automation Playbook: 5 Workflows That Save 30+ Hours Per Week

The Numbers After 30 Days

I tracked everything. Every workflow, every run, every API call, every minute reclaimed. After 30 days of running five OpenClaw automation workflows against real business workloads - client work, content production, code review, and operations - the results were concrete enough to put numbers to.

32 hours per week reclaimed. $47/month in total API costs.

That is not a rough estimate. I ran a lightweight time-tracking script alongside OpenClaw and logged exactly what the agent was doing versus what I previously did manually. The 32 hours is the delta between the two. The $47 is pulled directly from my Anthropic billing dashboard - I switched everything to Claude Sonnet 4.5 partway through and the costs dropped significantly without meaningful quality loss on most tasks.

The workflows are not magic. Each one took between two and six hours to configure, test, and tune. Two of them failed silently in the first week and required debugging. One of them I killed entirely after it started generating client drafts with the wrong tone and I hadn't built a proper review gate. But the five that survived and stabilized are genuinely transformative for how I spend my working hours.

This article documents each workflow in full: the configuration, the reasoning behind design decisions, the failure modes I encountered, and the actual time data. You can replicate any of these in an afternoon.

Series Context

This is Part 2 of the OpenClaw Mastery series. Part 1 covers the full architecture, installation, security configuration, and an overview of the seven highest-value business use cases with real community numbers. If you haven't read it, start there - I will not repeat the basics here.

This article assumes you have OpenClaw installed, connected to at least one messaging platform (I use Slack as the primary output surface), and have spent time reading Part 1's security section. Specifically, your permissions configuration should be locked down before you implement any workflow that touches external input like email or GitHub.

The Heartbeat System: OpenClaw's Scheduling Engine

Before getting into individual workflows, it is worth understanding how OpenClaw handles scheduled tasks. The term in the documentation is "heartbeat tasks" - a more descriptive name than cron because these tasks are not just fired-and-forgotten. They run in a context where the agent has access to its full memory layer, can reference previous run results, and can make decisions based on what happened last time.

Traditional cron fires a script. OpenClaw heartbeats fire a context-aware agent. The difference matters when you want behavior like "only email a client update if there are meaningful changes since the last update" - that kind of conditional logic requires memory, and heartbeat tasks have it.

The heartbeat configuration lives at ~/.openclaw/heartbeats.json. Here is a complete example showing the structure:

{
  "heartbeats": [
    {
      "id": "morning-ops",
      "name": "Morning Operations Dashboard",
      "schedule": "30 7 * * 1-5",
      "skill": "morning-briefing",
      "enabled": true,
      "budgetCap": {
        "maxCostPerRun": 0.08,
        "alertIfExceeded": true,
        "haltIfExceeded": false
      },
      "retryPolicy": {
        "maxRetries": 2,
        "retryDelaySeconds": 120
      },
      "notifications": {
        "onSuccess": false,
        "onFailure": "slack:#ops-alerts"
      },
      "memoryContext": {
        "include": ["previousBriefing", "pendingItems", "clientPriorities"],
        "retain": "7days"
      }
    },
    {
      "id": "inbox-pipeline",
      "name": "Intelligent Inbox Pipeline",
      "schedule": "0 */2 * * *",
      "skill": "inbox-triage-v2",
      "enabled": true,
      "budgetCap": {
        "maxCostPerRun": 0.15,
        "alertIfExceeded": true,
        "haltIfExceeded": true
      },
      "retryPolicy": {
        "maxRetries": 1,
        "retryDelaySeconds": 300
      },
      "notifications": {
        "onSuccess": false,
        "onFailure": "slack:#ops-alerts"
      }
    }
  ]
}

The key fields to understand: schedule is standard cron syntax. budgetCap is critical - set haltIfExceeded: true for any workflow that processes variable-length input (email is notorious for triggering unexpectedly large context windows). memoryContext controls which memory entries the agent has access to during the run, which lets you scope its context rather than letting it pull everything.

You can verify your heartbeat configuration and check next run times:

# List all configured heartbeats with next run time
openclaw heartbeat list
 
# Check status of a specific heartbeat
openclaw heartbeat status morning-ops
 
# Manually trigger a heartbeat for testing
openclaw heartbeat run morning-ops --dry-run
 
# View logs for the last 10 runs of a heartbeat
openclaw heartbeat logs morning-ops --last 10

The --dry-run flag is invaluable for development. The agent goes through the full planning and execution sequence but does not send any messages or write any files - it outputs what it would have done to your terminal. I run every new workflow in dry-run mode for at least three cycles before enabling it.

Workflow Overview at a Glance

Workflow 1: Morning Ops Dashboard

Weekly time saved: ~3 hours

The problem this solves is context-switching overhead at the start of the day. Before this workflow, my morning routine involved opening Gmail, scanning for urgent items, switching to Slack, catching up on overnight messages, checking GitHub for anything merged or broken, and then pulling up my calendar to understand the day's shape. Total time: 35 minutes on a good day, more often 50 minutes when something unexpected surfaced.

Now I get a single Slack message at 7:30am. I read it in five minutes. I know what is urgent, what my day looks like, and what needs a decision from me before 10am.

How It Works

The skill connects to Gmail (read-only), Slack (read channel history for specified channels), GitHub (pull request and issue status), and Google Calendar. It runs at 7:30am Monday through Friday. The agent synthesizes all four sources into a structured briefing and posts it to my #morning-ops Slack channel.

The Skill Configuration

{
  "skill": "morning-briefing",
  "version": "1.2.0",
  "description": "Daily morning operations briefing from four sources",
  "sources": {
    "gmail": {
      "enabled": true,
      "permissions": "readonly",
      "filters": {
        "since": "yesterday-6pm",
        "labels": ["INBOX", "IMPORTANT"],
        "excludeLabels": ["Promotions", "Social", "Updates"]
      },
      "classify": {
        "urgent": "response needed within 4 hours",
        "actionRequired": "response needed within 24 hours",
        "fyi": "informational, no action needed"
      }
    },
    "slack": {
      "enabled": true,
      "channels": ["#general", "#client-work", "#dev", "#alerts"],
      "since": "yesterday-6pm",
      "summarize": true,
      "flagMentions": true
    },
    "github": {
      "enabled": true,
      "repos": ["your-org/repo-1", "your-org/repo-2"],
      "include": ["openPRs", "failedChecks", "reviewRequested", "mergedYesterday"],
      "assignedToMe": true
    },
    "calendar": {
      "enabled": true,
      "lookahead": "today-and-tomorrow",
      "includePrep": true,
      "flagConflicts": true
    }
  },
  "output": {
    "destination": "slack:#morning-ops",
    "format": "structured-blocks",
    "sections": [
      "urgentItems",
      "calendarToday",
      "githubStatus",
      "slackHighlights",
      "suggestedFocusBlock"
    ],
    "tone": "concise, direct, no filler"
  },
  "budgetCap": {
    "maxInputTokens": 12000,
    "maxCostPerRun": 0.08
  }
}

The maxInputTokens: 12000 cap in the budget section is important. Without it, a heavy email overnight can balloon the context to 40,000+ tokens and push the per-run cost to $0.40+. I truncate aggressively and let the agent prioritize - it handles this gracefully, flagging when content was truncated so I know to check a source directly if needed.

Before and After

One practical tip: add a suggestedFocusBlock output section. The agent looks at your calendar gaps and email urgency and recommends a two-hour block for deep work. Mine appears at the bottom of the briefing as a two-sentence suggestion. It is not always right, but it forces me to think about protecting time before reactive work takes over.

Workflow 2: Intelligent Inbox Pipeline

Weekly time saved: ~8 hours

This is the most impactful single workflow I run and the most complex to configure correctly. Email is where most of my working time used to disappear, and the five-stage pipeline I built reduces it from a full-time presence to two focused 20-minute sessions per day.

The key design principle: the agent never sends anything autonomously. It triages, categorizes, drafts, and escalates - but every outgoing message goes to a draft queue that I review in one batch session. This took a couple of iterations to get right; my first version had the agent send drafts directly and I immediately killed it after it sent a client an email with the wrong project name.

The Five Stages

Stage 1: Triage - Classify each incoming email by type (client, lead, vendor, internal, newsletter, notification, personal) and urgency (immediate, today, this-week, archive). No action taken yet.

Stage 2: Categorize - Route each email to a labeled folder and apply tags. Newsletters get unsubscribed if they meet the staleness threshold (opened less than once in 60 days). Notifications get archived. Everything else gets a category label.

Stage 3: Auto-Draft - For emails in the "today" urgency bucket that match known response patterns (meeting requests, project status questions, standard client queries), generate a draft response and place it in Gmail Drafts. Do not send.

Stage 4: Escalate - For anything classified as "immediate" urgency, send me a Slack DM with a one-sentence summary and a direct link to the email.

Stage 5: Archive - Process anything older than 14 days with no pending action into the Archive label.

The Skill Configuration

{
  "skill": "inbox-pipeline",
  "version": "2.1.0",
  "description": "5-stage intelligent inbox processing pipeline",
  "trigger": "schedule:0 */2 * * *",
  "permissions": {
    "gmail": ["read", "label", "draft", "archive", "unsubscribe"],
    "slack": ["send-dm"],
    "sendEmail": false
  },
  "stages": {
    "triage": {
      "enabled": true,
      "classifyBy": ["sender", "subject", "body-preview"],
      "categories": ["client", "lead", "vendor", "internal", "newsletter", "notification", "personal", "unknown"],
      "urgencyLevels": {
        "immediate": "response expected within 2 hours based on sender history or explicit language",
        "today": "should respond same business day",
        "thisWeek": "non-urgent, can batch",
        "archive": "no action needed"
      }
    },
    "categorize": {
      "enabled": true,
      "autoUnsubscribe": {
        "enabled": true,
        "criteria": "newsletter not opened in 60+ days",
        "requireConfirmation": false,
        "logAll": true
      },
      "applyLabels": true,
      "archiveNotifications": true
    },
    "autoDraft": {
      "enabled": true,
      "scope": "urgency:today AND NOT category:unknown",
      "responsePatterns": [
        "meeting-request",
        "project-status-query",
        "availability-check",
        "invoice-acknowledgment",
        "general-client-query"
      ],
      "draftDestination": "gmail-drafts",
      "sendAutomatically": false,
      "tone": "professional, warm, concise",
      "signOff": "Best,\nLoic",
      "contextFromMemory": ["clientPreferences", "ongoingProjects", "previousResponses"]
    },
    "escalate": {
      "enabled": true,
      "scope": "urgency:immediate",
      "notification": {
        "channel": "slack-dm",
        "format": "one-sentence summary + gmail-deep-link",
        "includeSnippet": true,
        "maxSnippetLength": 200
      }
    },
    "archive": {
      "enabled": true,
      "olderThan": "14days",
      "requireNoPendingAction": true,
      "excludeCategories": ["client", "lead"]
    }
  },
  "budgetCap": {
    "maxCostPerRun": 0.15,
    "haltIfExceeded": true,
    "alertChannel": "slack:#ops-alerts"
  },
  "reporting": {
    "dailySummary": true,
    "summaryDestination": "slack:#morning-ops",
    "summaryTime": "17:30",
    "include": ["processed", "drafted", "escalated", "unsubscribed", "archived", "costPerRun"]
  }
}

The Pipeline Architecture

The draft review session is the key habit change this workflow requires. Instead of responding to email as it arrives, I open Gmail Drafts twice a day, review what the agent prepared, make any edits, and hit send. Most drafts need one or two word changes. About 20% I rewrite substantially. Maybe 5% I discard and write from scratch. The agent is not a ghostwriter - it is a first-draft accelerator.

Workflow 3: Code Review Automation

Weekly time saved: ~6 hours

This workflow monitors a set of GitHub repositories for new pull requests, runs a structured analysis pass, posts review comments directly to the PR, and sends me a Slack notification with a summary. I use it as a first-pass reviewer on every PR before I do my own human review.

The important framing: the agent does not replace human code review. It handles the mechanical, pattern-based parts - missing tests, obvious security issues, style inconsistencies, documentation gaps, and naming problems. By the time I open a PR, the agent has already surfaced most of the low-hanging issues and I can focus on logic, architecture, and context-specific concerns.

The Skill Configuration

{
  "skill": "github-pr-reviewer",
  "version": "1.4.0",
  "description": "Automated first-pass code review for GitHub PRs",
  "trigger": "webhook:github-pr-opened OR schedule:*/15 * * * *",
  "github": {
    "repos": ["your-org/repo-1", "your-org/repo-2"],
    "permissions": ["read:repo", "write:pull_requests"],
    "watchEvents": ["pull_request.opened", "pull_request.synchronize"],
    "ignoreLabels": ["skip-ai-review", "draft", "wip"],
    "ignorePaths": ["*.lock", "*.generated.*", "dist/", "build/"]
  },
  "reviewCriteria": {
    "security": {
      "enabled": true,
      "checks": [
        "hardcoded-credentials",
        "sql-injection-risk",
        "xss-risk",
        "unvalidated-input",
        "exposed-env-vars"
      ],
      "severity": "blocking"
    },
    "codeQuality": {
      "enabled": true,
      "checks": [
        "function-length-over-50-lines",
        "file-length-over-800-lines",
        "deep-nesting-over-4-levels",
        "missing-error-handling",
        "unused-variables",
        "missing-return-types"
      ],
      "severity": "warning"
    },
    "testing": {
      "enabled": true,
      "requireTestsForNewFunctions": true,
      "checkTestCoverage": false,
      "severity": "warning"
    },
    "documentation": {
      "enabled": true,
      "requireJsdocForPublicApi": true,
      "checkReadmeUpdates": false,
      "severity": "suggestion"
    },
    "style": {
      "enabled": true,
      "referenceConventions": true,
      "severity": "suggestion"
    }
  },
  "output": {
    "postComments": true,
    "commentPrefix": "[AI Review]",
    "groupBySeverity": true,
    "postSummaryComment": true,
    "summaryFormat": "blocking-count + warning-count + verdict",
    "slackNotification": {
      "channel": "slack:#dev",
      "format": "PR title + repo + blocking-issues-count + link",
      "onlyIfBlockingIssues": false
    }
  },
  "budgetCap": {
    "maxInputTokens": 20000,
    "maxCostPerRun": 0.25,
    "haltIfExceeded": true
  }
}

The Review Pipeline

The ignorePaths configuration matters more than it looks. Lock files and generated files can push a PR to 5,000+ lines of essentially meaningless diff that will exhaust your token budget without producing useful review output. Always exclude them.

One pattern I added after two weeks: a skip-ai-review label that engineers can apply to a PR to bypass the automated review. This is useful for configuration-only changes, dependency bumps, and hotfixes where the speed of merge matters more than a full analysis pass.

Workflow 4: Content Pipeline Orchestrator

Weekly time saved: ~10 hours

This is the most technically ambitious workflow and the biggest time saver. It uses a multi-agent architecture where four specialized agents coordinate to take a content brief from raw idea to scheduled draft. The orchestrator agent manages delegation, and each specialist handles its area of competence.

Before this workflow, producing one substantial article meant: 90 minutes of research, 30 minutes of outlining, two to three hours of drafting, 45 minutes of editing, and 20 minutes of formatting and scheduling across platforms. Total: four to five hours per piece.

After: I drop a brief (three to five bullet points describing the topic, target audience, and key points I want to make) into a Slack channel. The pipeline runs overnight. I wake up to a draft in Notion and a structured outline I can review against. The draft needs significant editing - the agents do not write in my voice - but the research is done, the structure is solid, and the first pass exists. My active involvement per piece dropped from four hours to ninety minutes.

The Multi-Agent Configuration

{
  "skill": "content-pipeline",
  "version": "3.0.0",
  "description": "Multi-agent content production pipeline: brief to scheduled draft",
  "trigger": "slack-message:#content-briefs",
  "agents": {
    "orchestrator": {
      "model": "claude-sonnet-4-5",
      "role": "Coordinate the pipeline. Parse the brief, delegate to specialist agents in sequence, validate each output before passing to the next stage, and compile the final package.",
      "memory": {
        "access": ["contentStrategy", "toneGuide", "audienceProfiles", "previousArticles"],
        "writeBack": ["completedPieces", "topicsCovered"]
      }
    },
    "researcher": {
      "model": "claude-haiku-4-5",
      "role": "Research the topic. Find supporting data, statistics, examples, and counterarguments. Produce a structured research document with sources.",
      "tools": ["webSearch", "webScrape"],
      "constraints": {
        "maxSources": 15,
        "requireRecentData": "2024-present",
        "avoidSources": ["low-domain-authority sites", "uncited claims"]
      },
      "output": "research-doc.md"
    },
    "outliner": {
      "model": "claude-haiku-4-5",
      "role": "Create a detailed content outline based on the research and brief. Include section headings, key points per section, supporting data to use, and word count targets.",
      "input": ["brief", "research-doc.md"],
      "output": "outline.md"
    },
    "drafter": {
      "model": "claude-sonnet-4-5",
      "role": "Write the full draft based on the outline and research. Match the established tone guide. Write in first person where appropriate. Target the specified word count.",
      "input": ["brief", "research-doc.md", "outline.md"],
      "toneGuide": "~/.openclaw/context/tone-guide.md",
      "output": "draft.md",
      "constraints": {
        "targetWordCount": "from brief",
        "perspectiveTone": "practitioner sharing experience, not marketing",
        "avoidPatterns": ["passive voice overuse", "filler phrases", "hedging without substance"]
      }
    },
    "editor": {
      "model": "claude-sonnet-4-5",
      "role": "Edit the draft. Fix factual inconsistencies, improve clarity, tighten language, ensure logical flow, check that all outline points were addressed, and format for the target platform.",
      "input": ["brief", "outline.md", "draft.md"],
      "platforms": ["notion", "blog-mdx"],
      "output": {
        "notion": "formatted-notion.md",
        "blog": "formatted-blog.mdx"
      }
    }
  },
  "platformFormatting": {
    "notion": {
      "exportFormat": "notion-blocks",
      "destination": "notion:database:content-drafts",
      "status": "draft"
    },
    "blog": {
      "exportFormat": "mdx",
      "destination": "file:~/Projects/blog/content/drafts/",
      "frontmatterTemplate": "~/.openclaw/templates/blog-frontmatter.yaml"
    },
    "linkedin": {
      "enabled": false,
      "exportFormat": "plain-text-adapted",
      "maxLength": 2800
    }
  },
  "approval": {
    "required": true,
    "approvalChannel": "slack:#content-review",
    "approvalFormat": "summary + notion-link + blog-link",
    "autoScheduleAfterApproval": false
  },
  "budgetCap": {
    "maxCostPerPipeline": 0.85,
    "alertIfOver": 0.60,
    "haltIfExceeded": true
  }
}

The tone-guide.md file referenced in the drafter config is a document I wrote myself - about 800 words describing my writing voice, phrases I use, phrases I avoid, structural preferences, and examples of past writing I think represents the style well. The agents reference it during drafting. It does not produce perfect results, but it produces drafts that are closer to my voice than generic AI output, which means less editing time.

The claude-haiku-4-5 model for the researcher and outliner stages is intentional. Those tasks do not require the reasoning depth of Sonnet and cost roughly one-eighth as much. On a typical article pipeline: researcher costs about $0.04, outliner $0.02, drafter $0.40, editor $0.25. Total under $0.75 per piece.

Tip on Brief Format

The pipeline produces better output when the brief is structured. I settled on this format:

Topic: [specific topic, not vague - include the angle]
Audience: [who is reading this, what they already know]
Key points: [3-5 bullet points of things that must be covered]
Tone: [any deviations from the default tone guide]
Word target: [approximate]
Avoid: [anything specifically off-limits]

A vague brief like "write about AI automation" produces generic output. A specific brief like "Topic: Why most OpenClaw deployments fail in the first month (focus on configuration mistakes, not feature gaps)" produces something usable.

Workflow 5: Client Communication Coordinator

Weekly time saved: ~5 hours

Client communication has a specific failure mode for consultants and agencies: the gap between "things have happened on the project" and "the client has been informed those things happened." That gap produces unnecessary check-in calls, status anxiety on the client side, and reactive communication that is always slightly behind reality.

This workflow closes that gap. It monitors Linear (for task completions and blockers) and GitHub (for merged PRs and failed deploys), synthesizes the relevant updates per client, generates a draft weekly status email, and puts it in my queue for review before sending. It also tracks client follow-up commitments and flags any that are approaching the deadline.

The Skill Configuration

{
  "skill": "client-comms-coordinator",
  "version": "1.8.0",
  "description": "Weekly client status updates and follow-up tracking",
  "trigger": "schedule:0 15 * * 5",
  "clients": [
    {
      "id": "client-alpha",
      "name": "Alpha Corp",
      "contactEmail": "pm@alphacorp.example",
      "linear": {
        "teamId": "TEAM_ALPHA",
        "include": ["completed", "inProgress", "blocked"]
      },
      "github": {
        "repos": ["your-org/alpha-project"],
        "include": ["mergedPRs", "failedDeployments", "openIssues"]
      },
      "reportPreferences": {
        "format": "executive-summary",
        "includeBlockers": true,
        "includeMetrics": false,
        "tone": "confident and direct, minimal hedging"
      }
    },
    {
      "id": "client-beta",
      "name": "Beta Inc",
      "contactEmail": "cto@betainc.example",
      "linear": {
        "teamId": "TEAM_BETA",
        "include": ["completed", "blocked"]
      },
      "github": {
        "repos": ["your-org/beta-project"],
        "include": ["mergedPRs"]
      },
      "reportPreferences": {
        "format": "detailed-technical",
        "includeBlockers": true,
        "includeMetrics": true,
        "tone": "technical peer, assume engineering background"
      }
    }
  ],
  "followUpTracking": {
    "enabled": true,
    "source": "memory:clientCommitments",
    "alertDaysBeforeDeadline": 2,
    "alertChannel": "slack-dm",
    "overdueFlagInReport": true
  },
  "output": {
    "destination": "gmail-drafts",
    "subject": "[Weekly Update] {clientName} - Week of {weekDate}",
    "approvalRequired": true,
    "approvalChannel": "slack:#client-comms",
    "approvalFormat": "client-name + summary-bullets + gmail-draft-link"
  },
  "requireHumanApproval": {
    "beforeSend": true,
    "approvalTimeout": "24hours",
    "onTimeout": "escalate-slack-dm",
    "neverAutoSend": true
  },
  "budgetCap": {
    "maxCostPerClient": 0.10,
    "maxCostPerRun": 0.30,
    "haltIfExceeded": true
  }
}

The neverAutoSend: true flag is non-negotiable for client-facing communication. I do not care if I forget to approve a draft before the weekend - the agent waits, escalates to me via DM, and waits again. It never sends on my behalf without explicit approval. The cost of an incorrect client communication is too high to trust an autonomous send path.

The follow-up tracking is the part I underestimated when I built this. When you tell a client "I'll send you the design mockups by Thursday," that commitment goes into the agent's memory via a structured note in Slack:

/openclaw remember client:alpha-corp commitment:"Send design mockups" deadline:"this Thursday"

The agent then tracks that commitment, surfaces it in the Tuesday briefing ("you have a client delivery due Thursday - no draft detected yet"), and includes it in the Friday status report as either complete or flagged as open.

Observability and Monitoring

Running five automation workflows without visibility into their behavior is how you end up with runaway costs, silent failures, and agents doing things you didn't expect. I spent the first two weeks of deployment flying partially blind, and it showed - one workflow ran 47 times in a single day due to a misconfigured schedule trigger before I caught it.

Now I have a monitoring setup that I check in under five minutes every morning, and it gets surfaced automatically in the morning briefing.

Log Analysis

OpenClaw writes structured logs to ~/.openclaw/logs/ in JSONL format. Each log entry contains the workflow ID, run timestamp, duration, token usage, cost, outcome, and a serialized action trace.

# Total cost for a specific workflow in the last 7 days
cat ~/.openclaw/logs/runs.jsonl | \
  jq 'select(.workflowId == "inbox-pipeline" and .timestamp > "2026-03-06") | .cost' | \
  paste -sd+ | bc
 
# Failed runs in the last 24 hours
cat ~/.openclaw/logs/runs.jsonl | \
  jq 'select(.status == "failed" and .timestamp > "'$(date -v-1d +%Y-%m-%dT%H:%M:%S)'") | {id: .workflowId, error: .error, time: .timestamp}'
 
# Average cost per workflow over the past 30 days
cat ~/.openclaw/logs/runs.jsonl | \
  jq -r '[.workflowId, .cost] | @tsv' | \
  sort | awk '{sum[$1]+=$2; count[$1]++} END {for (k in sum) print k, sum[k]/count[k]}'
 
# Longest-running executions (useful for cost debugging)
cat ~/.openclaw/logs/runs.jsonl | \
  jq 'select(.durationMs > 60000)' | \
  jq '{id: .workflowId, duration: .durationMs, cost: .cost, timestamp: .timestamp}' | \
  sort -t: -k2 -rn | head -20

A structured log entry looks like this:

{
  "runId": "run_01HZXQM8P2KFJN3T9VW7",
  "workflowId": "inbox-pipeline",
  "timestamp": "2026-03-12T10:00:03.421Z",
  "status": "success",
  "durationMs": 34820,
  "model": "claude-sonnet-4-5",
  "usage": {
    "inputTokens": 8432,
    "outputTokens": 1847,
    "totalTokens": 10279
  },
  "cost": 0.0847,
  "actions": [
    {"type": "gmail.read", "count": 23, "durationMs": 1204},
    {"type": "gmail.label", "count": 18, "durationMs": 892},
    {"type": "gmail.draft", "count": 4, "durationMs": 15432},
    {"type": "gmail.archive", "count": 6, "durationMs": 743},
    {"type": "slack.send", "count": 1, "durationMs": 312}
  ],
  "summary": {
    "processed": 23,
    "drafted": 4,
    "escalated": 0,
    "archived": 6,
    "unsubscribed": 2
  }
}

The Monitoring Dashboard

I built a simple shell script that generates a summary view from the log files. It runs as part of the morning briefing skill and the output gets included in the Slack message:

The 75% success rate on the Content Pipeline is the number that stands out - and it stands out intentionally. One run failed because the researcher agent timed out on a web scrape, and another failed because the outliner produced a structure the drafter agent flagged as insufficiently specific. Both failures were caught by the orchestrator and surfaced in the monitoring. Without this visibility, I would have assumed the pipeline was producing four drafts per week when it was actually producing three.

Setting Up Cost Alerts

The budget cap configuration handles per-run limits, but I also set up a monthly aggregate alert:

# Add to ~/.openclaw/alerts.json
{
  "alerts": [
    {
      "id": "monthly-cost-threshold",
      "type": "aggregate-cost",
      "period": "calendar-month",
      "threshold": 60.00,
      "notification": "slack-dm",
      "message": "OpenClaw monthly spend approaching budget limit"
    },
    {
      "id": "consecutive-failures",
      "type": "failure-streak",
      "workflowId": "*",
      "threshold": 3,
      "notification": "slack-dm",
      "message": "Workflow {workflowId} has failed {count} times in a row"
    },
    {
      "id": "anomalous-run-cost",
      "type": "cost-spike",
      "threshold": 3.0,
      "comparedTo": "7-day-average",
      "notification": "slack-dm"
    }
  ]
}

The anomalous-run-cost alert has caught two issues: once when a PR with an unusually large generated file hit the code review workflow, and once when the inbox pipeline encountered a thread with an enormous quoted email chain. In both cases the run completed within the hard cap but the spike was worth investigating.

ROI Calculator

The time-savings claims are real, but they mean different things depending on how you value your time and how long setup takes.

The $13,600 number deserves honest qualification: it assumes every saved hour has equal value and gets redirected to billable or high-value work. In practice, some recovered time goes to better rest, some to low-value tasks, and some to genuine high-value work. The real ROI is significant regardless - even if only half the recovered time generates value, the math is still overwhelming at these cost levels.

Common Pitfalls

I made most of these mistakes in the first two weeks. Some were cheap to fix; a couple cost me real time.

Over-automation. The instinct when everything starts working is to automate everything. Fight it. Every workflow you add is a failure mode you need to monitor, a configuration you need to maintain, and a budget item you need to track. Start with the two or three highest-value workflows, run them for four weeks, understand their behavior, then consider adding more.

Ignoring the logs. OpenClaw's log files are not optional reading material. They are the primary mechanism for catching silent failures, unexpected cost spikes, and agent behavior outside your intended scope. The 47-runs-in-one-day incident I mentioned earlier would have been caught in the first hour if I had been monitoring the log. Set up the cost alerts before you deploy your first workflow.

No budget caps. Every workflow with variable input should have a hard cost cap with haltIfExceeded: true. Email threads, large PR diffs, and long web pages can push context windows to unexpected sizes. Without caps, a single edge case can consume your monthly budget in an afternoon. I run with a $60/month aggregate limit and per-workflow daily limits as a second layer.

Unaudited community skills. The AgentSkill ecosystem has genuinely useful contributions, and it has skills that request more permissions than they need or call external endpoints you didn't authorize. Read the source code of any community skill before installing it. This is not optional. A skill is code that runs in your agent runtime with access to your connected accounts.

Not setting approval gates. Every workflow that touches external communication - email, Slack, client updates - should have an approval gate. The temptation to skip the approval step because "the drafts are usually fine" is exactly backwards: the approval step exists for the cases where the draft is not fine. One incorrect client email costs more goodwill than a hundred correct ones generate.

Treating the agent as infallible. The agent makes mistakes. It misclassifies email urgency, misses context in code reviews, and generates content drafts that miss the point of the brief. The workflows I have described are built around this assumption - the agent handles the mechanical, high-volume layer and a human reviews before anything consequential happens. Remove that human layer and you will eventually have a mistake you cannot take back.

What's Next in This Series

In Part 3, I compare OpenClaw head-to-head against n8n and Make.com. The comparison is not about which tool is best in absolute terms - it is about which tool fits which context. There are workflows where n8n is clearly the right choice (reliable, auditable, production-grade scheduled tasks), workflows where Make.com wins (fast setup for structured integration chains), and workflows where OpenClaw's agentic capabilities are the only approach that actually works.

I'll share the real cost comparison at every scale, the integration patterns that work best when you combine OpenClaw with a traditional workflow tool, and the specific signals that tell you which tool to reach for when you're starting a new automation project.

Need help designing automation workflows for your business? Let's talk through your setup - I'll identify the highest-ROI workflows for your specific context and help you configure them with the monitoring, budget controls, and approval gates they need to actually hold up in production.