Workflow DevKit

This setup handles transient retries automatically while stopping permanent failures immediately. You can track everything without a coordinator service, dead letter queues, or complex retry policies. Explore the interactive demo on v0: v0.app/chat/yNVqbF72C…

Using Promise.allSettled() provides parallel execution alongside per-channel failure tracking. Each step is independent, so throwing a FatalError stops retries for that specific channel while the others continue.

Sending an alert to four channels sequentially means the last channel waits for the first three. If you send them in parallel without coordination, you lose track of which specific channels failed. Promise.allSettled() provides the best of both worlds.

No queue. No cron. No dead-letter table. Exponential backoff in a for-loop that survives restarts. Explore the interactive demo on v0: v0.app/chat/retry-bac…

The backoff is just math in a local variable. `sleep()` pauses for real wall time and zero compute while waiting. Crash between attempts? The loop picks up exactly where it left off.

Traditional: a retry queue, a backoff column, and a cron to sweep stuck jobs. Workflow: a for-loop with `sleep()`:

No database rows required. Just a local array that tracks the whole payment lifecycle. Explore the interactive demo on v0: v0.app/chat/webhook-b…

The webhook is scoped to one order. `for await` suspends between events at zero compute. Each hit runs as a `"use step"`, retried independently. `ledger` is a local array. It survives across events, restarts, and deploys.

30 Days of Workflow DevKit — Day 4 — Payment Webhooks What if your webhook tracked an order from first charge to final refund — remembering every event — without a database? `createWebhook()` can do that in a simple loop:

No wasted tokens. No half-written output. Cancel, keep what's good, fix the prompt, rerun. Explore the interactive demo on v0: v0.app/chat/safe-canc…

Each `"use step"` function runs to completion or not at all. `run.cancel()` exits at the next step boundary. Completed sections are preserved in your dashboard, pending ones are dropped. The cancelled run is yours to inspect.

30 Days of Workflow DevKit — Day 3 — Easy Cancel You tweaked the system prompt and kicked off a test workflow. Three sections in, every paragraph reads like a fever dream. Stop the run, keep what's there, fix the prompt. All thanks to a simple cancel():

That's the whole email drip campaign. No scheduler. No queue. No state machine. Seven lines of async/await. Explore the interactive demo on v0: v0.app/chat/onboardin…

Each `sleep()` is real. `sleep("4d")` pauses for four actual days. Deploy in between? It picks up exactly where it left off. Each send is a `"use step"` which retries independently.

30 Days of Workflow DevKit — Day 2 — Email Drip Campaign You need to send 4 emails over 7 days. So you set up a cron, a state table, a "last sent" column, retry logic... Or you write this:

Explore the WDK Approval Gate demo on v0: v0.app/chat/approval-…

The token is deterministic. `order_approval:${orderId}` Put it in an email. Wire it to a Slack action. Call it from a CLI, a support tool. Send it anywhere. No setup required.

30 Days of Workflow DevKit — Day 1 — Approval Gate You need a human in the loop. So you build: a webhook endpoint, a database row, a polling cron, a timeout cron, a cleanup cron... Or ship a few lines of TypeScript with WDK:

Adding the new Workflow DevKit skill will help your coding agent: 1. Follow recommended patterns 2. Find the best documentation 3. Inspect projects with the Workflow DevKit CLI Install it now: `npx skills add vercel/workflow`