You told your agent to work through a list of tasks overnight. You wake up the next morning and check the task list. Some things are marked done, some are not, and you have no idea what order they ran in, how long each one took, whether anything went wrong partway through, or what was actually produced. The task list tracks current status. It does not track what happened. This article covers how to build an activity log that answers all of those questions in 30 seconds every morning.
TL;DR
OpenClaw does not create a persistent task activity log by default. Session history exists but gets compacted during long runs and disappears entirely when a new session starts. The fix is one addition to your task processor prompt: a logging instruction that writes a timestamped entry to a file after every task event (started, completed, failed). That file persists across sessions, survives compaction, and gives you a complete record of what ran and when without digging through session history.
Every indented block in this article 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, edit any files manually, or navigate any filesystem.
Why session history is not enough
Your agent keeps a conversation history for every session. In theory you could scroll through it and reconstruct what happened overnight. In practice this breaks down quickly for three reasons.
First, overnight sessions are long. A queue processor that ran six tasks over four hours produces hundreds of turns. Finding what matters means reading through tool calls, intermediate outputs, and reasoning steps that are irrelevant to the question “did the important tasks complete correctly?”
Second, compaction may have already removed the early parts of the session. If the agent ran long enough to trigger context management, the first tasks processed are summarized or gone entirely. You cannot reconstruct what happened to task 1 if the session history only goes back to task 4.
Third, session history disappears from active context when a new session starts. You would need to dig through archived session files to find last night’s run, and those files are not structured for quick review.
What happened in the last overnight session? What tasks were attempted, what succeeded, what failed, and what output was produced? If you cannot answer this fully from current context, tell me specifically what information is missing and why.
The answer to that question tells you exactly what an activity log would provide. Anything the agent cannot answer from current context is information that should have been written to a persistent file at the time it occurred.
What a task activity log actually is
A task activity log is a file your agent appends to during every session. Each line is a timestamped record of one event: a task started, a task completed successfully, a task failed, or a retry attempt. The file grows over time and never gets compacted because it is a workspace file on disk, not part of the session context.
The simplest format is one line per event:
2026-03-24T03:15:00Z | STARTED | task-07 | Send weekly digest 2026-03-24T03:16:42Z | COMPLETED | task-07 | Send weekly digest | 102s 2026-03-24T03:16:42Z | STARTED | task-08 | Clean up old memory entries 2026-03-24T03:19:01Z | FAILED | task-08 | Clean up old memory entries | Error: file not found 2026-03-24T03:19:01Z | RETRY | task-08 | Clean up old memory entries | attempt 2/3
Five fields: timestamp, event type, task ID, task name, and an optional note (duration for completions, error for failures). That is all you need to reconstruct a full picture of what ran overnight.
Create a task activity log at workspace/queue-activity.log. Use this format for each line: ISO-8601 timestamp, pipe, event type in uppercase (STARTED/COMPLETED/FAILED/RETRY/SKIPPED), pipe, task ID, pipe, task name, pipe, optional note. Open in append mode so new entries are added to the end without overwriting previous ones. Write a test entry now to confirm the file was created correctly.
Adding logging to your task processor
Creating the log file is the easy part. The second step is making sure your agent writes to it automatically during every task run. This requires adding logging instructions to your task processor prompt.
The instructions need to cover four events:
- Task started: write when the task is picked up, before any work begins. This entry exists even if the task never completes, giving you evidence that the task was running when the session terminated.
- Task completed: write when the task finishes successfully, with the elapsed time if available.
- Task failed: write when an error is caught, with the exact error message. This is the entry you will be reading most carefully on bad mornings.
- Task retried: write before each retry attempt, with the current attempt count. This distinguishes between a task that failed on the first try and one that succeeded after three retries, which is useful for identifying fragile tasks.
Update my task processor prompt to include activity logging. After picking up each task, append a STARTED entry to workspace/queue-activity.log. After completion, append a COMPLETED entry with elapsed time. After any failure, append a FAILED entry with the error message. Before each retry, append a RETRY entry with the attempt count. Show me the updated prompt section before applying it.
The morning review workflow that takes 30 seconds
With logging in place, your morning review becomes a single command rather than an archaeological dig through session history. The target: open your agent, ask for a summary, read it in 30 seconds, know what needs attention.
Read workspace/queue-activity.log. Show me a morning summary covering the last 12 hours: how many tasks ran, how many completed successfully, how many failed or are in retry state, which tasks took longer than 5 minutes, and which tasks failed with their error messages. Format it as a brief list I can read in under a minute.
That command is worth saving as a shortcut. The morning summary is the first thing to run in a new session after overnight automation. Before adding new tasks, before checking anything else, pull the overnight summary and confirm nothing needs immediate attention.
Setting up a scheduled morning summary
Even better than asking for the summary manually is having it delivered automatically. A cron job that reads the activity log and sends the summary to Telegram means the report is waiting for you when you wake up, without having to open anything.
Create a cron job that runs at 7:30am America/New_York every day. It should read workspace/queue-activity.log, summarize everything from the last 12 hours, and send the summary to me via Telegram. Include task count, success count, failure count, and the name and error of any failed tasks. Keep the message under 400 characters.
Tracking task outputs and not just events
An event log tells you what ran. Sometimes you also need to know what the task produced. For tasks that create files, send messages, or transform data, logging the output location alongside the completion event saves time when you need to verify the result.
Update the logging instructions for my content generation tasks. After completing a task that writes a file, append a COMPLETED entry that includes the file path and word count. After completing a task that sends a message, include the channel and a 10-word summary of what was sent. I want to confirm outputs at a glance without opening each file.
Output tracking is also the mechanism for spotting tasks that technically completed but produced empty or malformed output. A task that writes a file and completes in under a second very likely wrote an empty file. A task that completes but the output path is not logged should trigger a follow-up check.
Read workspace/queue-activity.log. Look for any COMPLETED entries where the elapsed time was under 5 seconds for tasks that normally take longer. These may be tasks that completed without actually doing the work. List any suspicious completions from the last 24 hours.
Managing the activity log file as it grows over time
An activity log that appends indefinitely grows large. After a few months of daily automation, the file can get long enough that reading it becomes slow and searching it becomes cumbersome. Log rotation solves this by archiving old entries periodically.
Create a monthly maintenance task that runs on the first of each month. It should: copy workspace/queue-activity.log to workspace/logs/queue-activity-YYYY-MM.log (using the previous month’s year and month), then truncate the active log file to remove entries older than 7 days. The archive files preserve the full history; the active log stays small for daily use.
The rotation strategy depends on how much history you typically need. For most operators, 7 days in the active log plus monthly archives is sufficient. If you need to audit a specific date, you know which monthly archive to open. If you are reviewing a current issue, the active log has the recent entries at hand.
Activity logs for multiple agents or queues
If you have more than one queue or more than one agent, separate log files for each are easier to work with than a single combined log. A combined log from two active agents produces interleaved entries that are harder to read and harder to filter.
I have two separate task queues. Create separate activity log files for each: workspace/logs/queue-a-activity.log and workspace/logs/queue-b-activity.log. Update the processor instructions for each queue to write to its own log. Add a combined morning summary cron job that reads both logs and sends a unified report to Telegram, clearly labeled by queue.
Designing a log schema that serves multiple purposes
A minimal log with five fields (timestamp, event, task ID, name, note) covers the basics. As your automation grows more complex, you may find the log serving more purposes: cost tracking, performance monitoring, audit trails, debugging complex failures. Designing the schema to accommodate these uses from the start is easier than retrofitting it later.
Adding cost tracking to log entries
If you know which model each task uses and roughly how many tokens a task consumes, you can include cost estimates in the COMPLETED entry. Over time, the activity log becomes a cost breakdown by task type, which is far more useful than a global monthly API bill for understanding where spend is going.
Update the COMPLETED log entry format to include the model used and an estimated cost for the task run. Use the standard token costs for the model and a rough token count estimate based on typical task output length. I want to be able to read the log weekly and see which task types are driving API costs.
Adding session identifiers
When multiple overnight sessions run (a queue that spawns sub-agent sessions, or a long run split across a gateway restart), a session identifier in each log entry helps you group entries by run. Without it, the timestamps alone tell you when things happened but not which execution context they belong to.
Update the activity log format to include a session identifier at the start of each line: a short tag like SESSION-001 that increments each time the queue processor starts a new run. All log entries from the same run should share the same session tag. This makes it easy to group entries by execution run when reviewing the log.
Cross-referencing the log with task output files
The activity log records that a task ran and produced output. The output file contains the actual content. Cross-referencing the two gives you a complete picture: not just that a task completed but what it produced and whether the output is usable.
Read workspace/queue-activity.log for all COMPLETED entries in the last 24 hours. For each entry that references an output file, check whether that file exists and whether it is non-empty. Report any COMPLETED entries where the output file is missing or empty. These are tasks that technically logged a completion but did not actually produce usable output.
This cross-reference check is the difference between knowing a task completed and knowing a task produced a valid result. A task that writes an empty file has the same status entry as one that writes a full document. The cross-reference catches the difference in about 30 seconds.
Using the activity log for debugging
When something is wrong and you do not know where to start, the activity log is your first stop. It narrows the problem from “something is broken” to “this specific task failed at this time with this error.” That single starting point cuts diagnostic time down dramatically.
The four-question debug sequence
For any automation problem, ask these four questions in order using the activity log:
- Did the task run? (Is there a STARTED entry for it?)
- Did it complete or fail? (Is the last entry for this task a COMPLETED or FAILED entry?)
- If it failed, what was the error? (Read the note field on the FAILED entry)
- Has this happened before? (Filter the log by task ID and look at the last 10 entries for this task)
Help me debug task [task ID]. Read workspace/queue-activity.log and answer: did it run in the last 48 hours, did it complete or fail, what was the error if it failed, and has it failed before? Show me the relevant log entries directly.
Finding patterns in failures
A single failure is a one-off. A pattern of failures pointing to the same task or the same error message is a systemic problem. The activity log is the tool for distinguishing between the two.
Read workspace/queue-activity.log and analyze the last 30 days of FAILED entries. Are there any tasks that have failed more than three times? Are there any error messages that appear repeatedly across different tasks? Group the failures by task and by error type and show me a summary table.
Building alerts from the activity log
Rather than embedding alert logic in the task processor itself, you can run a separate monitoring cron job that reads the activity log periodically and fires alerts based on what it finds. This separation has advantages: the task processor stays simple, and the alerting logic can be changed without touching the task processor.
Create a cron job that runs every 30 minutes. It should read workspace/queue-activity.log and check for: any FAILED entry in the last 30 minutes, any task that has been in STARTED state for more than 20 minutes without a COMPLETED or FAILED entry (indicating a stalled task), and any gap in activity longer than 60 minutes during hours when the queue should be running (midnight to 6am). Send a Telegram alert for any of these conditions.
The stalled task detection is particularly useful for long-running tasks. A STARTED entry with no corresponding COMPLETED or FAILED entry after 20 minutes is a signal that something may have gone wrong mid-task before the failure handler could log the error. Without this check, a stalled task sits silently until the next morning review.
Sharing log summaries with others
If you are running automation for a project with other stakeholders, a weekly activity summary sent to a shared channel can replace manual status updates. The log has all the data; it just needs to be formatted for a non-technical audience.
Create a weekly summary cron job that runs every Monday at 9am America/New_York. Read workspace/queue-activity.log for the previous 7 days. Write a summary in plain language (no technical jargon, no log format, just sentences) covering: what automation ran last week, how many tasks completed successfully, any failures and what caused them, and whether anything needs follow-up. Send the summary to Discord.
Structured logs versus plain text logs
The plain text format described in this article is easy to read and easy to search with simple commands. For operators who want to query the log more systematically, a structured format like JSON Lines (one JSON object per line) is easier to process programmatically but harder to read at a glance.
The tradeoff is readability versus queryability. For most operators reviewing overnight runs interactively by asking their agent questions, plain text is the right choice. If you ever want to run automated analysis scripts against the log (calculate percentiles, produce charts, export to a dashboard), JSON Lines is worth the switch.
Should I use a plain text pipe-delimited format or JSON Lines for my activity log? I plan to review it interactively each morning by asking you questions, but I also want to run occasional automated analysis. Describe the tradeoffs for my specific use case and recommend one.
The log is only as good as what is written to it
An activity log that is written inconsistently is worse than no log, because it creates false confidence. If the log shows all completions and no failures, you may assume everything is fine when in reality the FAILED entries are just not being written. The most important thing to verify when setting up logging is that failure entries are actually written when tasks fail. Run a deliberate failure test and confirm the FAILED entry appears. Do not trust the logging setup until you have confirmed the failure path specifically.
Designing a log schema that serves multiple purposes
A minimal log with five fields (timestamp, event, task ID, name, note) covers the basics. As your automation grows more complex, you may find the log serving more purposes: cost tracking, performance monitoring, audit trails, debugging complex failures. Designing the schema to accommodate these uses from the start is easier than retrofitting it later.
Adding cost tracking to log entries
If you know which model each task uses and roughly how many tokens a task consumes, you can include cost estimates in the COMPLETED entry. Over time, the activity log becomes a cost breakdown by task type, which is far more useful than a global monthly API bill for understanding where spend is going.
Update the COMPLETED log entry format to include the model used and an estimated cost for the task run. Use the standard token costs for the model and a rough token count estimate based on typical task output length. I want to be able to read the log weekly and see which task types are driving API costs.
Adding session identifiers
When multiple overnight sessions run (a queue that spawns sub-agent sessions, or a long run split across a gateway restart), a session identifier in each log entry helps you group entries by run. Without it, the timestamps alone tell you when things happened but not which execution context they belong to.
Update the activity log format to include a session identifier at the start of each line: a short tag like SESSION-001 that increments each time the queue processor starts a new run. All log entries from the same run should share the same session tag. This makes it easy to group entries by execution run when reviewing the log.
Cross-referencing the log with task output files
The activity log records that a task ran and produced output. The output file contains the actual content. Cross-referencing the two gives you a complete picture: not just that a task completed but what it produced and whether the output is usable.
Read workspace/queue-activity.log for all COMPLETED entries in the last 24 hours. For each entry that references an output file, check whether that file exists and whether it is non-empty. Report any COMPLETED entries where the output file is missing or empty. These are tasks that technically logged a completion but did not actually produce usable output.
This cross-reference check is the difference between knowing a task completed and knowing a task produced a valid result. A task that writes an empty file has the same status entry as one that writes a full document. The cross-reference catches the difference in about 30 seconds.
Using the activity log for debugging
When something is wrong and you do not know where to start, the activity log is your first stop. It narrows the problem from “something is broken” to “this specific task failed at this time with this error.” That single starting point cuts diagnostic time down dramatically.
The four-question debug sequence
For any automation problem, work through these four questions in order using the activity log:
- Did the task run at all? (Is there a STARTED entry for it?)
- Did it complete or fail? (Is the last entry for this task a COMPLETED or FAILED entry?)
- If it failed, what was the error? (Read the note field on the FAILED entry)
- Has this happened before? (Filter the log by task ID and look at the last 10 entries for this task)
Help me debug task [task ID]. Read workspace/queue-activity.log and answer: did it run in the last 48 hours, did it complete or fail, what was the error if it failed, and has it failed before? Show me the relevant log entries directly.
Finding patterns across failures
A single failure is a one-off. A pattern of failures pointing to the same task or the same error message is a systemic problem. The activity log is the tool for distinguishing between the two.
Read workspace/queue-activity.log and analyze the last 30 days of FAILED entries. Are there any tasks that have failed more than three times? Are there any error messages that appear repeatedly across different tasks? Group the failures by task and by error type and show me a summary table.
Building alerts from the activity log
Rather than embedding alert logic directly in the task processor, you can run a separate monitoring cron job that reads the activity log periodically and fires alerts based on what it finds. This separation keeps the task processor simple: the alerting logic can be changed without touching task processing at all.
Create a cron job that runs every 30 minutes. It should read workspace/queue-activity.log and check for: any FAILED entry in the last 30 minutes, any task that has been in STARTED state for more than 20 minutes without a corresponding COMPLETED or FAILED entry (stalled task), and any gap in activity longer than 60 minutes during hours when the queue should be running. Send a Telegram alert for any of these conditions.
The stalled task detection is particularly useful for long-running tasks. A STARTED entry with no corresponding COMPLETED or FAILED entry after 20 minutes means something stopped mid-task before the failure handler could log an error. Without this check, a stalled task sits silently until the next morning review.
Sharing log summaries with others
If you are running automation for a project with other stakeholders, a weekly activity summary sent to a shared channel replaces manual status updates. The log has all the data; it just needs to be formatted for a non-technical reader.
Create a weekly summary cron job that runs every Monday at 9am America/New_York. Read workspace/queue-activity.log for the previous 7 days. Write a summary in plain language covering: what automation ran last week, how many tasks completed, any failures and what caused them, and whether anything needs follow-up. Send the summary to Discord.
Structured logs versus plain text logs
The plain text format described in this article is easy to read and easy to search by asking your agent questions. For operators who want to process the log programmatically, a structured format like JSON Lines (one JSON object per line) is easier to parse but harder to skim at a glance.
For most operators reviewing overnight runs interactively, plain text is the right default. If you want to run analysis scripts, produce charts, or export to a dashboard, JSON Lines is worth the switch. Start with plain text and migrate if you find yourself needing systematic queries the agent cannot handle conversationally.
Should I use plain text pipe-delimited format or JSON Lines for my activity log? I plan to review it interactively each morning by asking you questions, but I also want to run occasional automated analysis. Describe the tradeoffs for my specific setup and recommend one.
The log is only as good as what is written to it
An activity log written inconsistently is worse than no log at all because it creates false confidence. If the log shows completions and no failures, you may assume everything is fine when in reality FAILED entries simply are not being written. Before relying on your log, run a deliberate failure test and confirm the FAILED entry appears. Do not trust the setup until you have verified the failure path specifically.
Common questions
The activity log file exists but it is empty. Why is nothing being written to it?
The logging instruction was probably added to the prompt after the session that runs the queue started, or it is only applied to new tasks and the queue processor has not been restarted to pick up the updated instructions. Check two things: first, open the task processor prompt and confirm the logging instruction is actually there and references the correct file path. Second, run a single manual test task and confirm an entry appears in the log immediately after. If nothing appears, the instruction is either not being read or has the wrong file path. Check whether the instruction says workspace/queue-activity.log or a full absolute path, and whether the workspace directory resolves correctly from the session context.
The log has entries for some tasks but not others. Why are some tasks missing?
Most commonly a task failed before the STARTED entry was written, which means the agent never got far enough to log it. This is why writing the STARTED entry should be the absolute first step when picking up a task, before any tool call or file read. If the STARTED entry itself is missing, the task either was never picked up or failed at the very beginning of processing. Check whether the task is still showing as PENDING in the queue file to determine whether it was picked up at all.
Can I read the activity log from my phone without opening the agent?
The cleanest way is the scheduled morning summary cron job that sends to Telegram. That gives you the summary delivered to your phone at a set time with no action required on your part. If you want on-demand access, you can trigger the summary manually by sending a command to your agent from Telegram, which works from your phone as well. Reading the raw log file from your phone is possible if you have a files app with SFTP support pointed at your server, but the summary cron job is easier for daily use.
My activity log is growing very fast. One session added thousands of entries. What is happening?
The logging instruction is probably writing to the log more frequently than intended: logging intermediate steps within a task rather than only the start, completion, and failure events. Review the logging instruction in your processor prompt and make sure it only fires for the four defined events (STARTED, COMPLETED, FAILED, RETRY). If it says something like “log every tool call” or “log every step,” that explains the high volume. Prune the log back to the correct four events and set the rotation to run more frequently until the file is at a manageable size.
Can I search the activity log for a specific task name or date range?
Yes. Ask your agent to filter the log by the criteria you need: “Read workspace/queue-activity.log and show me all entries for task-07 from the last 30 days” or “Show me all FAILED entries from March 2026.” The agent can read and filter the log file the same way it reads any workspace file. For very large log files, filtering by a specific task ID or date prefix is faster than reading the whole file.
I want to see a week-over-week trend in my task success rate. Is that possible from the log?
Yes, if the log has been running for at least two weeks. Ask your agent to read the full log and calculate success rate (COMPLETED / (COMPLETED + FAILED)) broken down by week. If you have monthly archives, include those in the analysis for longer trend data. A declining success rate trend often points to a growing infrastructure problem: an API key approaching expiration, a service with increasing latency, or a task whose input data is gradually becoming more complex than the prompt can handle.
What is the difference between the activity log and the compaction summary?
The activity log is a file you control, written explicitly by your agent during task processing. It contains exactly what you told it to write: task events with timestamps and notes. The compaction summary is generated automatically by OpenClaw when context fills up. It summarizes the session conversation and preserves what OpenClaw determines is important. The compaction summary is an artifact of context management; the activity log is a deliberate record-keeping mechanism. The activity log is more reliable, more structured, and more searchable for task-specific questions. Use the activity log for operational review. The compaction summary is a fallback for reconstructing context after a long session, not a replacement for deliberate logging.
How often should I review the activity log?
Every morning if you run overnight automation, and after any session where you asked your agent to complete a significant batch of tasks. The morning review takes 30 seconds once the log and summary cron are in place. For passive monitoring, the scheduled morning summary cron job covers daily review automatically. The deeper manual review (looking at failure patterns, success rate trends, suspicious fast completions) is worth doing once a week if your automation is running daily.
My log entries are out of order. Some earlier timestamps appear after later ones. Why?
This happens when two tasks run in rapid succession and both attempt to write log entries close together. The entries are written in the order the append calls complete, which is not always the same as the order the events occurred if there is any concurrency involved. The simplest fix is to add a brief sleep between tasks in the queue processor so entries are written sequentially. If you need strict ordering for audit purposes, switch to JSON Lines format and sort by the timestamp field when reviewing rather than relying on file order.
Queue Commander
Activity log setup, morning report cron, and failure alerting in one package
Pre-built logging instructions for your task processor, the morning summary cron job, log rotation setup, and output tracking for content and message tasks. Everything from this article pre-configured and ready to drop in.