Skip to main content

Overview

Mission Control’s scheduler runs automated maintenance tasks in the background without manual intervention. Handle database backups, stale data cleanup, agent heartbeat checks, webhook retries, and Claude Code session scanning.
The scheduler initializes automatically on startup and runs tasks based on configured intervals. No user action required.

Accessing Scheduler Status

1

Navigate to Settings

Click Settings in the left navigation rail.
2

Open Background Tasks

Scroll to the Background Tasks section.
3

View Task Status

See last run time, next scheduled run, and enabled/disabled status for each task.

Via API

Query scheduler status programmatically:
curl http://localhost:3000/api/scheduler \
  -H "x-api-key: your-api-key"
Response:
[
  {
    "id": "auto_backup",
    "name": "Auto Backup",
    "enabled": true,
    "lastRun": 1735696800000,
    "nextRun": 1735783200000,
    "running": false,
    "lastResult": {
      "ok": true,
      "message": "Backup created (2456KB)",
      "timestamp": 1735696800000
    }
  }
]

Scheduled Tasks

Five background tasks run automatically:

1. Auto Backup

Purpose: Create database backups to prevent data loss. Schedule: Daily at ~3 AM UTC (relative to process start time) What It Does:
1

Create Backup

Copies SQLite database to .data/backups/mc-backup-{timestamp}.db
2

Log Event

Records backup creation in audit log with file size
3

Prune Old Backups

Deletes backups older than retention count (default: keep 10)
Configuration:
{
  "general.auto_backup": true,
  "general.backup_retention_count": 10
}
Manual Trigger:
curl -X POST http://localhost:3000/api/scheduler \
  -H "Content-Type: application/json" \
  -H "x-api-key: your-api-key" \
  -d '{"action": "trigger", "taskId": "auto_backup"}'
or use the dedicated backup endpoint:
curl -X POST http://localhost:3000/api/backup \
  -H "x-api-key: your-api-key"
Filenames follow the pattern: mc-backup-YYYY-MM-DD_HH-MM-SS.dbExample: mc-backup-2026-03-04_03-00-00.db

2. Auto Cleanup

Purpose: Remove stale records based on retention policies. Schedule: Daily at ~4 AM UTC What It Does:
1

Delete Old Activities

Remove activity feed entries older than configured days
2

Delete Old Audit Logs

Remove audit trail entries older than configured days
3

Delete Old Notifications

Remove notifications older than configured days
4

Delete Old Pipeline Runs

Remove pipeline execution history older than configured days
5

Clean Token Usage File

Remove token records from tokens.json older than configured days
6

Log Summary

Record total number of deleted records in audit log
Configuration:
{
  "general.auto_cleanup": true,
  "retention.activities": 90,
  "retention.auditLog": 180,
  "retention.notifications": 30,
  "retention.pipelineRuns": 60,
  "retention.tokenUsage": 90
}
Set retention to 0 to disable cleanup for a specific record type. Records will be kept indefinitely.
Manual Trigger:
curl -X POST http://localhost:3000/api/cleanup \
  -H "x-api-key: your-api-key"

3. Agent Heartbeat Check

Purpose: Mark agents offline if they haven’t sent a heartbeat recently. Schedule: Every 5 minutes What It Does:
1

Query Stale Agents

Find agents with status != 'offline' and last_seen < threshold
2

Mark Offline

Update agent status to offline and set updated_at timestamp
3

Log Activity

Create activity feed entry: “Agent marked offline (no heartbeat for Xm)”
4

Create Notification

Notify operator: “Agent offline:
5

Audit Log

Record which agents were marked offline
Configuration:
{
  "general.agent_heartbeat": true,
  "general.agent_timeout_minutes": 10
}
If agents are frequently marked offline, increase agent_timeout_minutes or ensure agents are sending heartbeats regularly.
Manual Trigger:
curl -X POST http://localhost:3000/api/scheduler \
  -H "Content-Type: application/json" \
  -H "x-api-key: your-api-key" \
  -d '{"action": "trigger", "taskId": "agent_heartbeat"}'

4. Webhook Retry

Purpose: Retry failed webhook deliveries with exponential backoff. Schedule: Every 60 seconds What It Does:
1

Query Failed Deliveries

Find webhook deliveries with status = 'failed' and next_retry <= now
2

Check Circuit Breaker

Skip webhooks that have exceeded max retries (circuit open)
3

Retry Delivery

Send HTTP request to webhook URL with payload
4

Update Status

Mark as success or increment retry count
5

Calculate Backoff

Set next_retry using exponential backoff (1s, 2s, 4s, 8s, 16s, …)
Configuration:
{
  "webhooks.retry_enabled": true,
  "webhooks.max_retries": 5,
  "webhooks.retry_backoff": 2.0
}
Manual Trigger:
curl -X POST http://localhost:3000/api/webhooks/retry/{deliveryId} \
  -H "x-api-key: your-api-key"
After 5 consecutive failures, the webhook enters “circuit open” state:
  • No further retry attempts
  • Delivery status set to circuit_open
  • Operator notification created
  • Manual intervention required to reset

5. Claude Session Scan

Purpose: Auto-discover and track local Claude Code sessions. Schedule: Every 60 seconds What It Does:
1

Scan Projects Directory

Read ~/.claude/projects/ for active projects
2

Parse JSONL Transcripts

Extract conversation history from transcript files
3

Extract Token Usage

Parse API responses for token counts (input, output, total)
4

Calculate Cost

Multiply tokens by Claude model pricing
5

Store in Database

Upsert session records with source = 'claude-code'
Configuration:
{
  "general.claude_session_scan": true
}
Environment:
MC_CLAUDE_HOME=~/.claude
Manual Trigger:
curl -X POST http://localhost:3000/api/claude/sessions \
  -H "x-api-key: your-api-key"
Claude Code must be installed and have at least one project for scanning to work. Sessions are marked active if updated within the last hour.

Task Configuration

Enable/disable tasks via Settings API:

Enable a Task

curl -X PUT http://localhost:3000/api/settings \
  -H "Content-Type: application/json" \
  -H "x-api-key: your-api-key" \
  -d '{
    "general.auto_backup": true
  }'

Disable a Task

curl -X PUT http://localhost:3000/api/settings \
  -H "Content-Type: application/json" \
  -H "x-api-key: your-api-key" \
  -d '{
    "general.auto_cleanup": false
  }'

View All Settings

curl http://localhost:3000/api/settings \
  -H "x-api-key: your-api-key"

Retention Policies

Configure how long records are kept:
Key: retention.activitiesDefault: 90 daysActivity feed entries (task updates, agent changes, etc.)

Set Retention Policy

curl -X PUT http://localhost:3000/api/settings \
  -H "Content-Type: application/json" \
  -H "x-api-key: your-api-key" \
  -d '{
    "retention.activities": 60,
    "retention.auditLog": 365,
    "retention.notifications": 14
  }'
Retention policies apply during the next cleanup run. Previously deleted data cannot be recovered.

Scheduler Initialization

The scheduler starts automatically when Mission Control launches:
  1. Agent Sync — Sync agents from openclaw.json on startup
  2. Task Registration — Register all 5 background tasks
  3. Staggered Start — Backup scheduled for ~3 AM, cleanup for ~4 AM (relative to start time)
  4. Tick Loop — Check every 60 seconds for due tasks

Startup Log

Scheduler initialized - backup at ~3AM, cleanup at ~4AM, 
heartbeat every 5m, webhook retry every 60s, claude scan every 60s

Monitoring Task Execution

Last Run Information

Each task tracks:
  • lastRun — Timestamp of most recent execution
  • nextRun — Timestamp of next scheduled execution
  • running — Boolean indicating if task is currently executing
  • lastResult — Result of most recent execution:
    • ok — Success/failure boolean
    • message — Human-readable summary
    • timestamp — When result was recorded

Example Result Messages

  • Auto Backup: "Backup created (2456KB)"
  • Auto Cleanup: "Cleaned 147 stale records"
  • Heartbeat Check: "All agents healthy" or "Marked 2 agent(s) offline: researcher-01, analyst-02"
  • Webhook Retry: "Retried 3 deliveries: 2 succeeded, 1 failed"
  • Claude Scan: "Synced 2 sessions: mission-control, demo-project"

Audit Trail

All scheduled task executions are logged to the audit trail:
curl http://localhost:3000/api/audit?action=auto_backup \
  -H "x-api-key: your-api-key"
Response:
[
  {
    "id": 123,
    "action": "auto_backup",
    "actor": "scheduler",
    "detail": {
      "path": ".data/backups/mc-backup-2026-03-04_03-00-00.db",
      "size": 2514944
    },
    "created_at": 1735696800
  }
]

Troubleshooting

  1. Check if task is enabled in settings
  2. Verify nextRun timestamp is in the past
  3. Confirm scheduler initialized (check startup logs)
  4. Look for errors in lastResult.message
  1. Verify .data/backups/ directory exists and is writable
  2. Check disk space: df -h .data/
  3. Review permissions: ls -la .data/backups/
  4. Check audit log for detailed error message
  1. Confirm retention policies are set (not 0)
  2. Verify records are older than retention days
  3. Check if task is enabled: general.auto_cleanup = true
  4. Manually trigger cleanup and review result
Increase timeout:
curl -X PUT http://localhost:3000/api/settings \
  -H "Content-Type: application/json" \
  -d '{"general.agent_timeout_minutes": 20}'

Best Practices

Backup Strategy

1

Enable Auto Backup

Always keep general.auto_backup = true in production.
2

Set Retention Count

Keep 10-30 backups depending on disk space and change frequency.
3

External Backup

Copy .data/backups/ to offsite storage weekly (e.g., S3, Google Drive).
4

Test Restoration

Periodically verify backups can be restored by copying to a test environment.

Retention Tuning

  • High-traffic systems — Reduce retention to 30-60 days to save disk space
  • Audit compliance — Increase audit log retention to 365+ days
  • Development — Use shorter retention (7-14 days) to keep database small

Heartbeat Tuning

  • Reliable networks — 10-minute timeout is fine
  • Unreliable networks — Increase to 20-30 minutes to avoid false positives
  • Local development — Consider disabling heartbeat checks entirely

Next Steps

Agent Management

Configure agent heartbeat intervals and SOUL files

Real-Time Monitoring

Monitor task execution in the activity feed