Workflows that survive a closed tab: durable waits with checkpoints and chrome.alarms

“Browser automation dies when you close the tab” is the standard objection to running workflows in an extension. For a while it was true for AWFlow too: a workflow with a “wait 3 days, then check again” step only worked if you left a tab open for three days.

This post is about how runs can now pause for up to 30 days, survive a closed tab, a browser restart or an extension update, and resume where they stopped. It’s the same mechanism that lets a run pause for a human approval.

The constraint: MV3 has no long-lived process

In Manifest V3 the background is a service worker, and Chrome suspends it when it’s idle. setTimeout(resume, 3 * DAY) is useless there: the worker is gone long before the timer fires. The page that runs the engine (the extension’s app tab) can be closed by the user at any time.

So a long wait has to be two things:

1. a serialized snapshot of the run, stored somewhere that survives restarts, and
2. a wake-up call that the browser itself owns.

In an extension, those are chrome.storage.local and chrome.alarms. If you want the bigger picture of what a browser can and can’t do compared with a server, browser vs server automation covers it.

How a run pauses

Let a node ask to pause

Normally a node’s execute() returns output. A node that needs to wait returns a suspend request instead:

type SuspendRequest = {
  resumeKey: string;              // filled in by the engine
  kind: 'approval' | 'timer' | (string & {});
  prompt?: string;                // shown in the "waiting" row
  meta?: Record<string, unknown>; // e.g. { resumeAt: 1735689600000 }
};

The engine spots it and throws a SuspendSignal to unwind the work queue back to the place where the queue and visited sets are in scope. That’s where the checkpoint gets written. (One subtlety: the node runner’s own catch must re-throw this signal instead of turning it into a node failure.)

Write a checkpoint that’s actually resumable

My first version stored “which node paused, plus its input”. It broke immediately on real workflows. A useful checkpoint needs everything the scheduler would need to continue as if nothing happened.

Here is the shape in code:

const checkpoint = {
  resumeKey, workflowId, pausedNodeId, kind, meta,
  pausedInput,
  queue: queue.map(n => n.id),     // what was about to run
  visited: [...visited],
  wasVisited: [...wasVisited],     // see below
  nodeOutputs,                     // so downstream $('Node') references still resolve
  runVariables: runVariables.snapshot(),
  nodeExecutionCtx,                // per-node scratchpads: loop cursors, batch offsets
  parentLink,                      // a paused sub-workflow must still resume its parent
  createdAt: new Date().toISOString(),
};

Two bugs taught me the less obvious fields:

• Loops. An iterating Loop node is moved out of visited on each pass. If you only save outputs of visited nodes, a pause inside a loop body resumes with the loop’s current item gone. Save outputs from visited ∪ wasVisited.
• Batch cursors. A “Split in Batches” node keeps its offset in a per-node scratchpad. Capture the scratchpad of every node, not just visited ones, because the loop node is exactly the one that’s been un-marked when you pause.

Serialize defensively, fail loudly

Node outputs are user-controlled (a Code node can return anything), so a BigInt or a circular reference would crash the run at the moment it tries to pause. So the checkpoint goes through a few guards before it is stored.

If the checkpoint can’t be saved, the run fails loudly at that node. A pause that silently didn’t persist would be the worst outcome: the user thinks it’s waiting and nothing ever resumes it.

How it wakes up

For a timer suspend, saving the checkpoint also arms a one-shot alarm named after the resume key:

if (cp.kind === 'timer' && typeof cp.meta?.resumeAt === 'number') {
  chrome.alarms.create(`resume:${cp.resumeKey}`, { when: cp.meta.resumeAt });
}

In practice the app page asks the service worker to do it, because the worker owns the alarms API and the onAlarm listener. Here is the full round, from pause to resume.

Re-arm the alarms you lost

Alarms don’t survive everything. An extension update, for example, can clear them. So on startup the worker reconciles: list the timer checkpoints, list the existing alarm names, and create the missing ones.

function computeMissingResumeAlarms(checkpoints, existingAlarmNames) {
  const existing = new Set(existingAlarmNames);
  return checkpoints
    .filter(cp => cp.kind === 'timer' && typeof cp.meta?.resumeAt === 'number')
    .filter(cp => !existing.has(`resume:${cp.resumeKey}`))
    .map(cp => ({ name: `resume:${cp.resumeKey}`, when: cp.meta.resumeAt }));
}

It’s a pure function, so it’s trivially unit-tested, and it’s the piece that makes the design trustworthy rather than “usually works”. A deadline already in the past fires right away, so a laptop that was asleep through the deadline resumes as soon as the browser is back.

Where the thresholds come from

• Under 1 minute stays in memory. chrome.alarms doesn’t fire reliably below about a minute, and a 5-second wait isn’t worth a storage round-trip. Short waits stay plain timers.
• Up to 30 days. An upper bound, so nobody schedules an alarm for 2031 by typo.
• One pause per input, not per item. A Wait node pauses once for the whole batch. Per-item pauses can’t be checkpointed cleanly. If you want per-item waits, wrap the step in a Loop.

One mechanism, many kinds

Once the plumbing existed, other kinds came almost for free:

• approval pauses until a person clicks approve. Because it’s waiting on a human, the extension signals it: a badge, a sound, and an OS notification when the app isn’t focused. It can even render the approval card on the web page you’re on.
• “Poll until” resumes on a timer, checks a condition, and if it’s not met yet, suspends again. A resume that is allowed to re-suspend turned out to be the key primitive.
• Sub-workflows pause with a parentLink, so the parent run continues once the child finishes.

The approval kind is the easiest to see in a real workflow. This docs example fills a web form from saved values, but stops before touching the page until you approve:

If page watching is your use case rather than forms, monitoring competitor prices shows the other side: a trigger that reacts when a page changes.

The honest limit

This is durable, not always-on. The alarm fires when the browser is running. If your laptop is off at the deadline, the run resumes when you next open Chrome, not at 3:00:00 sharp.

For “every 30 seconds, 24/7” you still want a server. For “wait until Thursday, check the price, ask me before buying”, it’s enough, and there’s nothing to host.

If you’re building something similar in your own extension, here is the short version.

AWFlow is free to install. I’m happy to answer questions, especially from anyone who’s done this with IndexedDB instead of storage.local.