How an automation runs
Once an automation is armed, it runs on the platform's own infrastructure — not inside a chat session, not on your machine. This page is what happens under that surface: how often it checks, what a single run actually does, what gets written down, and how the platform keeps a fleet of automations from stepping on each other or hammering the sites they watch.
The run model
An automation is not a program that sits running. It is a behavior the platform checks on.
- Cadence
- The platform re-checks armed automations on a fine, regular rhythm
- Idle check
- Costs nothing, writes nothing — the common case
- A real run
- Executes the recipe, delivers, and records one entry
- Runs on
- The platform's infrastructure, not a chat session or your device
- Survives
- Closed tabs, ended sessions, months of quiet
Think of the platform as walking past every armed automation on a regular beat and asking a single question: is there anything to do right now? For a scheduled automation, the answer is yes only when its time has arrived. For a watch, only when the source has genuinely changed. For a webhook or email automation, only when something actually arrived. The vast majority of these glances find nothing, and finding nothing is designed to be effectively free.
Checks are free
This is the property that makes it reasonable to watch something continuously, forever.
A check that finds nothing to do does not spend AI, does not send anything, and does not add a row to your run history. It compares the current state of the world against what the automation saw last time, decides there is nothing new, and moves on. Because that comparison is deterministic — a hash, a timestamp, a stored fingerprint — it is essentially costless.
The practical consequence: an automation that watches a page which only changes twice a year is quiet and cheap for the other 363 days. You are never billed for vigilance, only for the runs that actually produce something.
A run, start to finish
When a trigger really fires, here is the shape of the run that follows.
- 01The trigger firesThe scheduled time arrives, a webhook is received, an email lands at the automation’s private address, a watched source changes, or an upstream automation finishes. Incoming payloads are saved before anything runs, so the run can always be reproduced later.
- 02The recipe executes in orderEach step runs in sequence — fetch, decide, shape, deliver — and any step can be gated on a condition so it only runs when it should. A step that needs judgment makes one bounded call to the model you chose; every other step is deterministic.
- 03It deliversThe result is handed to its destination: a message in the home conversation, an email, a Slack channel, or an action in a connected tool. Delivery is confirmed, not assumed — a send that fails is recorded as a failure, never as a success.
- 04It records the runOne entry lands in the run history with what happened, how long it took, how much it cost, and a readable step-by-step trace. This is the thing you inspect, in place of a flowchart.
What gets recorded
Run history is signal, not noise — so only runs that did something are written down.
If every idle check produced a log line, your run history would be thousands of “nothing happened” entries with the occasional real event buried inside. Instead, only runs that matter are recorded: a delivery, a detected change, a judgment call, a repair. Idle checks leave no trace at all.
That keeps the history readable — every entry is something the automation actually did on your behalf — and it is the same history that feeds the board, the run traces, and the health signal. See Observability.
| Kind of run | Recorded? | Why |
|---|---|---|
| Idle check, nothing changed | No | The common case; would drown the signal |
| A watched source changed | Yes | You want to see it, even before delivery |
| A delivery went out | Yes | Proof of what was sent, and where |
| A judgment call was made | Yes | Records the decision and its confidence |
| A repair was attempted | Yes | The diagnosis and outcome belong in history |
| A run failed | Yes | Kept verbatim so a repair has something to read |
Good manners toward sources
An automation that watches a site should be a good citizen of that site.
When many people all watch the same popular page, a naive system would send that page a burst of identical requests every single check — fifty watchers becoming fifty simultaneous hits. The platform prevents this in two ways, automatically, with no configuration from you.
| Guard | What it does | Effect |
|---|---|---|
| Shared fetch | The first fetch of a page in a short window is reused for everyone else watching it in that window | Fifty watchers of one page produce one request, not fifty |
| Rate limiting | Each source has a fleet-wide budget of requests per minute; extra checks wait their turn | No single site is ever hammered, however many people watch it |
| Backing off | If a source says it is busy, the check retries later with a widening gap instead of pushing harder | A struggling source is given room, not more load |
Many automations at once
Your fleet and everyone else's run together without queueing behind each other.
When a batch of automations come due in the same moment — several morning digests that all fire at 8, say — they run concurrently rather than one after another. Each run is claimed exactly once, so the same automation never double-fires even under load, and a slow run never holds up the others behind it. From your side this is invisible: your 8am digest arrives at 8, regardless of how many other people also scheduled something then.
Where a run lives
An automation is not a hidden daemon. Every run has an address you can read.
A run executes on the platform’s infrastructure, but it is always tied to its home conversation — the chat thread that belongs to the automation. Chat deliveries appear there, a repair posts its diagnosis there, and that is where you go to change the automation. There is deliberately no orphaned background process with no owner and no transcript: if an automation did something, there is a conversation where you can see it, and an entry in run history that records it.
Automations project so their home conversations stay out of your main thread list but remain one click away.