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, output routing, what stops a run) decide whether the schedule runs reliably or becomes a source of 2am mysteries.
15 min
is the lead agent's heartbeat cadence in a squad, with the other agents' heartbeats hourly, once you switch them on: agents wake, check their lanes, act, and go quiet. Everything sharper than that runs as an explicit scheduled task.
Source: Squad (formerly MissionControlHQ) docs, Schedule recurring workiShort answer
Put known recurring work in scheduled tasks (specific job, cadence, owner, model); let heartbeats carry the in-between judgment. Stagger runs across agents to avoid rate-limit bursts, pin deadline jobs with a cron expression, and set tasks to Notify me so results find you. There is no timeout to tune: every new task gets 24 hours. In Squad, all of it is editable from the dashboard: cadence, instructions, owner, and model 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 |
| No timeout to tune | New tasks get 24 hours; a task left with a short limit shows Raise to 24 hours |
| Deadline jobs get a pinned time | A cron expression sets the day and time; delete the task after it runs |
| Output goes where you are | Notify me sends you each result; the run history stays the audit trail |
Two mechanisms, one rhythm.
Heartbeats: the pulse
Once switched on, the lead wakes every 15 minutes and the others hourly, check their lanes, and act on what's pending.
Scheduled tasks: the calendar
Named jobs with a cadence, an owner, and a model.
Staggering: the discipline
Runs spread across agents and minutes, never stacked at the hour.
Routing: the delivery
Notify me sends you each result; 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: on its interval (in Squad, every 15 minutes for the lead and hourly for the others, once you switch heartbeats on) the agent surfaces, checks its lanes (mentions and assigned missions), 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, output to the brief document." 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.
No timeout to tune
A scheduled task in Squad has no run time limit to set. The job editor has no timeout field, every new task gets 24 hours, and at each workspace computer restart any scheduled task limit below 86,400 seconds is raised to 86,400. Workspace defaults shows a Run time limit card that reads "Runs have no time limit." The reason is practical: a short limit stopped runs that were still working.
Stuck runs are a separate problem with a separate guard. A 15-minute no-progress watchdog can stop a run that shows no progress, but it skips a run while a tool call or compaction is in flight, and it does not see runs on the Claude Code lane. So no setting tells you when a run will stop, and a long run is not a fault in itself.
Older tasks can still carry a short limit from an earlier setting. The job editor shows that limit with a Raise to 24 hours button, and a leftover workspace limit shows a warning with Remove the limit. When a run does time out, its row in Runs offers Check the time limit, which opens that task's editor (or Workspace defaults for a run that is not scheduled). The fix is always to lift the limit, never to size it.
Deadline jobs and output routing
Two smaller features carry more weight than their size suggests. Deadline jobs get a pinned time: a Custom (cron) expression runs a task at a set day and time, right for deadline work ("send the proposal Thursday 9am") that deserves the reliability of a schedule. Schedules repeat, so delete the task once it has run, before it lives on as a recurring entry that someone eventually has to notice and remove.
Output routing decides whether results find you. Each scheduled task is set to Notify me, which sends you the result of each run, or Run quietly, which runs without sending a message, so the morning brief comes to you instead of waiting in a dashboard tab you had to remember to open. The run history records everything regardless: the setting changes whether 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 Squad, the schedule layer is dashboard-native: rename tasks, change cadence, update instructions, reassign the owning agent, and pick the model per task, all from the Scheduled screen. Health warnings flag a task that can never run and tasks that fire at the same minute (with a Stagger them fix), so schedules do not rot silently. Heartbeats live on the same screen: one scheduled task per agent, created switched off, and pausing an agent pauses all of its scheduled tasks.
A week on the schedule
A concrete squad's calendar, staggered and owned: Monday 7:00, the competitor sweep (research agent, output to the brief document). Daily 6:30, the morning brief (lead agent, Notify me). Daily 6:40, inbox triage (support agent, Run quietly). Friday 8:00, billing follow-ups (ops agent). Friday 16:00, the weekly report (lead, Notify me). Heartbeats (the lead's every 15 minutes, the others' hourly) carry everything unnamed: replies, mentions, new missions. One cron entry, "send the renewal proposal Thursday 9:00", ran once and was deleted. 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, long sweep runs included, because a long run needs no limit sized for it.
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 (15 min lead, hourly others) | 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. |
| An older task left with a short limit | Raise to 24 hours | A short limit stops runs that are still working. |
| Deadline job (send Thursday 9am) | Cron at a pinned time | Runs at the set time; delete it after it runs. |
| Morning brief you actually read | Notify me | Results should find you instead of waiting in a tab. |
Can you name the job and its cadence?
- If yes: sweep, brief, follow-ups→scheduled task with owner + model
- 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→cron at the deadline; delete it after it runs
Seeing failed runs in the run history?
- If a timeout on one task→Check the time limit, then Raise to 24 hours
- If errors on many tasks at the same minute→a staggering problem: spread them out
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? Not as a one-time entry: schedules repeat, on an interval preset or a cron expression. For deadline work (send the proposal Thursday 9am), a cron expression pins the day and time; delete the task once it has run so it does not live on as a recurring entry.
The operations
What timeout should a scheduled task have? None: a run time limit is not a setting. The job editor has no timeout field, and every new scheduled task gets 24 hours. A task left with a shorter limit from an earlier setting shows it with a Raise to 24 hours button, and each workspace computer restart raises any scheduled task limit below 86,400 seconds to 86,400. Separately, a 15-minute watchdog can stop a run that shows no progress, but it skips a run while a tool call or compaction is in flight.
How do I see output from scheduled runs without opening the dashboard? Set the task to Notify me, which sends you the result of each run, and turn on the Task completed email notification if you want an email when a scheduled task finishes. The dashboard's run history remains the audit trail either way.
Can I edit schedules without touching a terminal? Yes: rename tasks, change cadence, update instructions, reassign the owning agent, and pick the model per task, all from the Scheduled screen in the dashboard. Health warnings flag a task that can never run and tasks that fire at the same minute.
Sources
- Squad: homepage, get started, docs: schedule recurring work, docs: time limits
- Related on this site: Why Squad, Mission Control for OpenClaw
Last updated: September 2026. Product capabilities verified against the Squad docs as of September 2026.