An agent that only works when you message it is a chatbot with extra steps. What makes a squad always-on is the schedule layer: heartbeats that wake agents to check their lanes, and scheduled tasks that run specific jobs at specific times. The mechanics are simple; the details (staggering, timeouts, output routing) decide whether the schedule runs reliably or becomes a source of 2am mysteries.
30-60 min
is the typical heartbeat cadence for an always-on squad: agents wake, check their lanes, act, and go quiet. Everything sharper than that runs as an explicit scheduled task.
Source: MissionControlHQ docsiShort answer
Put known recurring work in scheduled tasks (specific job, cadence, owner, timeout); let heartbeats carry the in-between judgment. Stagger runs across agents to avoid rate-limit bursts, size timeouts to the work (roughly 300s routine, 600s complex), use one-time schedules for deadline jobs, and route outputs to your chat so results find you. In MissionControlHQ, all of it is editable from the dashboard: cadence, instructions, owner, model, and timeout per task.
Key takeaways
| Principle | What it means in practice |
|---|---|
| Known work gets a schedule | Heartbeats are for judgment, not for the Monday sweep |
| Stagger, never synchronize | Simultaneous wake-ups invite rate limits and retries |
| Timeouts match the work | ~300s routine, ~600s complex; errors mean raise it |
| Deadline jobs run once | One-time schedules auto-delete after running |
| Output goes where you are | Route results to chat; the run history stays the audit trail |
Two mechanisms, one rhythm.
Heartbeats: the pulse
Agents wake every 30-60 minutes, check their lanes, act on what's pending.
Scheduled tasks: the calendar
Named jobs with a cadence, an owner, a model, and a timeout.
Staggering: the discipline
Runs spread across agents and minutes, never stacked at the hour.
Routing: the delivery
Output lands in your chat; the run history records everything.
Why schedules make the squad
The difference between "AI I use" and "a team that works for me" is what happens while you sleep. Reactive agents produce work when prompted; a squad produces work on a rhythm: the Monday competitor sweep, the daily brief before your coffee, the Friday billing follow-ups. That rhythm is entirely a scheduling artifact. Take the schedule away and the squad reverts to a very capable chatbot waiting for input.
Schedules also change what you can promise. "The report ships every Friday" is an operational commitment you can make when a scheduled task owns it: repeatable, logged, and independent of anyone remembering. Habits scale poorly; cadences scale fine, and they keep scaling as the squad grows from three lanes to a dozen.
Heartbeats vs scheduled tasks
Two mechanisms share the schedule layer, and confusing them produces either waste or gaps.
A heartbeat is a general wake-up: every 30-60 minutes the agent surfaces, checks its lanes (mentions, pending tasks, new email), handles what it finds, and goes quiet. Heartbeats are for judgment in the in-between: the work you could not have named in advance.
A scheduled task is a named job with a cadence: "competitor sweep, Mondays 7:00am, owned by the research agent, 600-second timeout." Scheduled tasks are for work you can name: if you know the job and when it should run, write it down as one.
The practical rule: anything you find yourself expecting ("the brief should be here by 8") belongs in a scheduled task, because expectations deserve guarantees. Leaning on heartbeats for known work means the job runs "sometime in the next hour, if the agent notices", which is how briefs arrive at 8:47 and trust erodes. Heartbeats backfill the rest. Scheduled tasks are also the cheaper habit at scale: they can be staggered deliberately, while heartbeat-heavy squads burn tokens re-checking lanes that scheduled tasks would have handled precisely.
Staggering: the detail that prevents 2am mysteries
The classic scheduling mistake is synchrony: nine agents all waking at the top of the hour, all calling the same provider in the same second. The result is a self-inflicted burst: rate limits trip, tasks retry, retries collide with the next wave, and the run history fills with errors that look like an outage but are really a calendar problem.
The fix is boring and total: stagger everything. Spread scheduled tasks across minutes and agents so load stays flat: the sweep at :00, the brief at :10, billing at :20. Staggering reduces API costs (retries are pure waste), avoids rate limits, and makes genuine provider incidents distinguishable from self-inflicted ones in the history. If two tasks genuinely must run back-to-back, chain them as one task instead of gambling on two schedules landing in order.
Timeouts sized to the work
Every scheduled run gets a time budget, and the budget should match the job. Routine runs (a lane check, a short brief) fit comfortably in about 300 seconds. Complex ones (deep research, long-document work) warrant 600 or more. Undersized timeouts kill legitimate work mid-run; oversized ones let a stuck run burn its full window before anyone learns it was stuck.
The tuning loop is reactive and cheap: when the run history shows timeout errors on a task, open it and raise that task's limit. Resist global bumps: a workspace where everything has a 900-second timeout has replaced information ("this task is unusually heavy") with noise.
One-time schedules and output routing
Two smaller features carry more weight than their size suggests. One-time schedules run a task at a specific date and time, then auto-delete: right for deadline work ("send the proposal Thursday 9am") that deserves the reliability of a schedule but should not live on as a recurring entry that someone eventually has to notice and remove.
Output routing decides where results land. A scheduled task can deliver its output directly to your chat channel, so the morning brief arrives in Telegram where you already are, instead of in a dashboard tab you had to remember to open. The run history records everything regardless: routing changes where results find you, not where they are kept.
Editing schedules like a product, not a server
On a bare agent runtime, schedule changes are config-file edits over SSH: workable for a developer, disqualifying for anyone else. In MissionControlHQ, the schedule layer is dashboard-native: rename tasks, change cadence, update instructions, reassign the owning agent, pick the model per task, and adjust timeouts, all from Agent Configuration. Model-availability warnings flag any schedule pointed at a model that no longer exists before you save, so schedules do not rot silently. Heartbeats get the same treatment: intervals, models, notifications, and custom instructions per agent or workspace-wide, with a one-click disable for the whole layer when you need silence.
A week on the schedule
A concrete squad's calendar, staggered and sized: Monday 7:00, the competitor sweep (research agent, 600s, output to the brief document). Daily 6:30, the morning brief (lead agent, 300s, routed to Telegram). Daily 6:40, inbox triage (support agent, 300s). Friday 8:00, billing follow-ups (ops agent, 300s). Friday 16:00, the weekly report (lead, 600s, routed to Telegram). Heartbeats every 45 minutes carry everything unnamed: replies, mentions, new tasks. One one-time entry, "send the renewal proposal Thursday 9:00", ran and deleted itself. Nothing fires at the top of the hour together; nothing depends on a human remembering; the run history reads as a flat line of green with two timeouts on the sweep, which is how its owner learned to raise it to 600 in the first place.
Schedule design cheat sheet
| Scenario | Best pick | Why |
|---|---|---|
| Work you can name and expect | Scheduled task | Expectations deserve guarantees, not heartbeat luck. |
| Judgment in the in-between | Heartbeat (30-60 min) | Mentions, replies, and new work you couldn't pre-name. |
| Nine tasks at 9:00am sharp | Stagger across minutes/agents | Synchrony = rate limits + retry storms. |
| Deep research or long documents | 600s+ timeout | Undersized budgets kill legitimate work mid-run. |
| Deadline job (send Thursday 9am) | One-time schedule | Runs once, auto-deletes, no cleanup debt. |
| Morning brief you actually read | Route output to chat | Results should find you where you already are. |
Can you name the job and its cadence?
- If yes: sweep, brief, follow-ups→scheduled task with owner + timeout
- If no: depends on what arrives→heartbeat coverage
Does it recur?
- If weekly/daily→recurring schedule, staggered off the hour
- If once, at a deadline→one-time schedule; it auto-deletes
Seeing timeout errors in the run history?
- If on one heavy task→raise that task's timeout (600s+)
- If on many tasks at the same minute→you have a staggering problem, not a timeout problem
Frequently asked questions
The model
What is the difference between a heartbeat and a scheduled task? A heartbeat is a general wake-up: the agent checks its lanes and decides what needs doing. A scheduled task is a specific job on a specific cadence: run the competitor sweep Monday 7am. Recurring work with a known shape belongs in scheduled tasks; heartbeats cover the in-between judgment.
Why stagger scheduled tasks instead of running them all at once? Nine agents waking simultaneously is a burst that invites rate limits and wasted retries. Staggering runs across agents smooths the load, reduces API costs, and avoids the thundering-herd failure where everything errors together at the top of the hour.
Can a scheduled task run just once at a specific time? Yes: one-time schedules run at a set date and time and auto-delete after running. They suit deadline work (send the proposal Thursday 9am) that deserves scheduling but should not live on as a recurring entry.
The operations
What timeout should a scheduled task have? Match it to the work: around 300 seconds suits routine heartbeat-style runs, while complex tasks (deep research, long documents) warrant 600 or more. Timeout errors in the run history are the signal to raise a specific task's limit rather than a global one.
How do I see output from scheduled runs without opening the dashboard? Route it: scheduled tasks can send their output straight to your chat channel, so the morning brief lands in Telegram where you already are. The dashboard's run history remains the audit trail either way.
Can I edit schedules without touching a terminal? Yes: rename tasks, change cadence and timeout, update instructions, reassign the owning agent, and pick the model per task, all from Agent Configuration in the dashboard. Availability warnings flag a task pointed at a model that no longer exists.
Sources
- MissionControlHQ: homepage, early access
- Related on this site: Why MissionControlHQ, Mission Control for OpenClaw
Last updated: July 2026. Product capabilities verified against the live dashboard changelog as of July 2026.