Vercel Workflows turns ordinary async TypeScript into durable runs. Each 'use step' function is a unit with its own retries and a recorded result, and an event log lets the run resume after a crash or a deploy without repeating the steps that already finished. We moved four Monogram Tools jobs onto it because each had outgrown one function invocation, and we kept one long job off it on purpose.
What is Vercel Workflows, and what happened to the Workflow DevKit?
Vercel Workflows is the managed service built on the open-source Workflow SDK, which launched as the Workflow Development Kit. You install the workflow package, mark an orchestrating function with 'use workflow' and each unit of work with 'use step', and the compiler turns them into routes in your own deployment. On Vercel, Vercel Functions run the steps, Vercel Queues dispatch them, and managed persistence keeps every input, output and event.
Monogram Tools runs the workflow package inside its Next.js app, wired in with withWorkflow in the Next config. Four tools now hold six durable run functions between them. AEO Audit has one, Launch Video has two for its tour plan and its render, the Knowledge Base has one for extraction retries, and Screen Recorder has two for processing and rendering.
How is a workflow different from after(), waitUntil or a cron?
after() and waitUntil keep work going after the response inside the same invocation, so that work lives and dies with the instance and its maximum duration. A cron starts work on a clock, inside one invocation as well. A workflow survives both limits. When an invocation nears its ceiling the run carries on in a new one by replaying its event log, and the run itself has no maximum duration, though it is capped at 10,000 steps and 25,000 events.
All four of our jobs ran in after() or on a cron before they moved. AEO Audit shows why that stopped working. A run makes about 60 grounded model calls, and our spec records the slowest engines averaging 75 to 90 seconds a probe and the whole run at roughly 45 minutes of serial work. Inside one 300-second invocation, the audit needed a 150-second soft deadline. Liveness was a second problem: in after(), a run that died had nothing to mark it dead. Now each phase and each probe is its own step, and the run is bounded by a budget of its own rather than by the function ceiling.
What happens to a run during a crash or a deploy?
The run replays from its event log. Vercel records every step's input and output, and on replay a finished step returns its recorded result instead of running again, so the run continues at the step it was on. Skew protection keeps an in-flight run on the deployment that started it, so shipping new code does not change a run halfway through.
Launch Video's tour plan is the clearest case. In after(), a deploy or a crash could lose a plan. As a durable run it reads the site, plans the scenes and parks for review, each as a step.
How do retries work, and how do you avoid paying for the same thing twice?
Steps retry up to 3 times by default, you can set maxRetries per step, a FatalError stops retrying at once, and a RetryableError sets the delay. Retries mean a step can run more than once, so the docs ask you to make side effects idempotent.
AEO Audit fences paid work with step boundaries. A step that calls a model makes that call and returns the result; the write is the next step. A failed write is then retried without paying for the model call again, and its paid steps retry only once. We also resolve each tenant's model credentials inside the step that needs them, so no key is ever passed as a step input or stored in the event log.
Launch Video's render applies the same idea to its scenes. It voices one scene per step, so a scene that fails is retried alone and the scenes before it are kept. Recording stays a single Vercel Sandbox step, retried once, because it fits one invocation.
How does a workflow wait for something outside it?
Two primitives cover it. sleep() pauses a run for seconds or months without holding compute, and a hook pauses it until an external event arrives, such as an approval or a webhook call.
Knowledge Base extraction retries use both. A recoverable failure on upload starts a run that sleeps out a 30, 60 and 120 second backoff and re-ingests the document. The run holds a hook keyed on the document, so a second run for the same document finds the hook taken and ends at once. Our 5-minute cron also starts a run for each document waiting on a retry, which covers documents saved through our agent or our MCP server.
Screen Recorder uses a webhook to wait on Vercel Sandbox. Each run starts a detached sandbox job, registers a webhook, and sleeps until the job calls back or a deadline passes. The job's marker file in Vercel Blob is what counts, not the call, so a callback that never arrives costs a wait rather than a stuck run. Transcription is one step per audio part, and edits coalesce into one render run per clip that waits for the edits to go quiet before rendering.
Vercel Workflows, Temporal or Inngest?
We chose Vercel Workflows because the runs compile into routes inside the deployment we already ship, and the steps run as the Vercel Functions we already operate. There is no worker fleet and no second service to deploy. Temporal classically executes workflow code on workers you run, and Inngest drives functions you expose over HTTP from its own orchestrator; both are mature, and both are reasonable when your compute does not live on Vercel. Speed and cost depend on the workload, so compare them on your own jobs.
What does Vercel Workflows cost?
Workflows bills events, data written and data retained, the functions that run your steps bill at normal compute rates, and the Vercel Queues that dispatch them bill at their own standard rates. A normal step produces three events and each retry adds one, so a run with thousands of tiny steps costs more than one that batches work. A run is also capped at 10,000 steps and 25,000 events, and replay slows past 2,000 events. Vercel's own guidance is to batch items into steps and split very long runs into child workflows.
When not to use Vercel Workflows
A job that fits one invocation and holds a lot of in-memory state between its turns is often better left alone. Journey, our site-walk tool, stays in after() with an 800-second function duration, the generally available maximum on Fluid compute. A walk is one agent conversation, and between two turns its state is the whole transcript plus what it has read and scored. Splitting that into a step per turn would ship all of it through every step's input and output, and a turn is not idempotent, because it appends its hops to the record as they land. An 800-second ceiling gives each walk about 2.7 times the 300-second default, which is the simpler design.
Workflow code itself must be deterministic, because replay has to take the same path through the recorded steps. I/O and Node APIs belong in a step, and so does anything that must be unguessable, such as a secret token, because inside the workflow the SDK makes Math.random and Date return the same values on every replay.
If you have a job that keeps hitting the function ceiling, our agentic AI engineering work covers this pattern, and you can tell us what you are building.
FAQ
Is the Workflow SDK tied to Vercel? The SDK is open source; Vercel Workflows is the managed way to run it on Vercel.
Can a workflow run for days? Yes. Run duration and sleep duration have no limit, but a run is capped at 10,000 steps and 25,000 events, and each step is still bound by the Vercel Functions maximum duration.
Do I still need a cron? Sometimes. Our Knowledge Base and Screen Recorder crons now reconcile and start durable runs instead of doing the work themselves.
Should credentials go into step inputs? No. Inputs and outputs are recorded in the event log, so resolve secrets inside the step.
Where can I read more? See our Vercel technology page.