Retry a Flaky Workflow Step

Retry and throttle one Upstash Workflow step without rerunning the others.

Introduction

30 Second Summary

When one task in a chain hits a temporary limit, repeating every task wastes time. The useful fix is to repeat only the part that stumbled.

In this project, you will deploy a three-step Upstash Workflow with one deliberately flaky API call. You will give that step its own retry count plus flow control, then use run history to prove the surrounding steps run once.

What You'll Build

Trigger ten workflow runs to watch the flaky middle step queue under its own limit while the surrounding steps stay untouched.

By the end of this project, you'll have:

A deployed three-step workflow that you can trigger while watching every step complete in the console.
A controlled failure test that reveals how the default settings retry the whole workflow.
Clear before-and-after run histories showing that only the flaky step retries while ten test runs queue under its flow control.
An optional Secret Mission to push your workflow reliability skills further.

Are there any prerequisites?

You need an Upstash account plus a deployable endpoint for the workflow. This lets Upstash call your workflow after you trigger a run.

Before We Start

Your Upstash Workflow needs a public endpoint before Upstash can call it. A missing account or local runtime would block every run before you reach the retry experiment.

This step prepares your Node.js environment. You will also authenticate the services needed for deployment without deploying anything yet.

In this step, get ready to:

Confirm that Node.js and npm are available.
Sign in to the Upstash Console.
Prepare a local project with the Upstash Workflow SDK and deployment access.

Check Node.js and npm

Node.js runs the JavaScript behind your workflow. Its installer includes npm, which adds the Workflow SDK to your project.

Press Cmd+Space (macOS) or the Windows key (Windows) to open your search bar.
Type Terminal on macOS or PowerShell on Windows.
Press Enter to open the terminal.
Check whether Node.js and npm are available by running these commands:

node --version
npm --version

What Do These Commands Check?

The first command prints your installed Node.js version. The second confirms that npm was installed alongside it.

✔️ I see two version numbers

Your runtime and package manager are ready. Keep this terminal open for the project setup.

ⓧ I see command not found

Node.js is missing from your computer or terminal path. The official Long Term Support installer includes npm.

Visit the Node.js download page.
Download the installer marked LTS for your operating system.
Run the installer with its default options.
Close your terminal after the installation completes.
Reopen your terminal through your operating system search.
Confirm the installation by running these commands:

node --version
npm --version

What Should You See?

Each command prints a version number when your terminal can find Node.js and npm. That output confirms the runtime is ready.

Still Seeing a Missing Command?

Restart your computer so the installer can finish updating your terminal path.

Use the official installer for your operating system if the downloaded file does not open correctly.

Ask for help with your installation issue.

Prepare cloud access

The Upstash Console stores Workflow run history and production credentials. You also need Vercel access so the project can deploy a public endpoint in the next step.

Open the Upstash Console in your browser.
Sign in with your Upstash account.
Create an account with Amazon, GitHub, Google, or email if you do not have one.
Select Workflow in the console navigation.
Choose the region you plan to use.
Locate QSTASH_TOKEN in the Quickstart section.

This token authorizes production requests through QStash. Keep it private because anyone with the value could use your account credentials.

Copy the token into your password manager for the deployment step.
Return to your terminal after the token is stored.
Install the Vercel CLI by running this command:

npm install -g vercel

What Does This Command Do?

The global installation makes the vercel command available from any project folder. The CLI handles deployment authentication from your terminal.

Wait for npm to finish installing the Vercel CLI.

Vercel CLI Installation Failed?

Confirm that npm --version worked in the previous check.

A permissions error can come from how Node.js was installed on your computer.

Get help fixing the Vercel CLI installation.

Vercel authentication may open your browser for account verification. The terminal waits while you complete that secure sign-in flow.

✔️ I already have a Vercel account

Start the Vercel sign-in flow by running this command:

vercel login

What Does This Command Do?

The command links the Vercel CLI to your existing account. Complete the verification in the browser when prompted.

You will see a successful login confirmation in the terminal after the browser flow finishes.

Browser Sign-In Did Not Complete?

Keep the terminal command running while you finish verification in the browser.

Start the command again if the verification link expires.

Get help with the Vercel login flow.

ⓧ I need a Vercel account

Start the Vercel account creation flow by running this command:

vercel signup

What Does This Command Do?

The command opens Vercel account registration. A completed sign-up also authenticates the CLI on your computer.

You will see a confirmation in the terminal when the new account is signed in.

Account Creation Did Not Finish?

Return to the browser page opened by the command.

Complete any email verification requested by Vercel.

Get help with Vercel account creation.

Create the local project

A Node.js project records its dependencies in package.json. This gives the workflow a reproducible home before you add its endpoint.

Move to your Desktop by running this command:

cd ~/Desktop

What Does This Command Do?

This moves your terminal to the Desktop. The project folder will be easy to find after it is created.

Create the retry-flaky-step folder by running these commands:

mkdir retry-flaky-step
cd retry-flaky-step
npm init --yes

What Does This Setup Create?

The first command creates the project folder on your Desktop.
The second command moves your terminal into that folder.
The final command creates package.json with default project details.

You should see a message confirming that npm wrote package.json inside the project folder.

Project Folder Already Exists?

Use the existing retry-flaky-step folder only if it does not contain another project.

Remove or rename the old folder before repeating the setup command if it contains unrelated files.

Get help checking the existing folder safely.

The Workflow SDK provides the functions that define durable steps. Installing it now records the dependency before any workflow code is added.

Install the Upstash Workflow SDK by running this command:

npm install @upstash/workflow

What Does This Installation Add?

npm downloads the Workflow SDK into node_modules. It also records the dependency in package.json for future installs.

The installation completes when npm returns to the command prompt without reporting a failed dependency.

SDK Installation Failed?

Confirm that your terminal is inside the retry-flaky-step folder.

Check your internet connection if npm reports a network or registry problem.

Get help with the SDK installation output.

Local development can use an automatic QStash development server. The setting keeps production credentials out of your local file while the SDK prepares local Workflow services.

Create .env.local with local development enabled by running this command:

echo QSTASH_DEV=true > .env.local

What Does This Setting Do?

The QSTASH_DEV=true setting tells the Workflow SDK to use its local QStash development server. Local testing does not need the production token you stored earlier.

Confirm the file contains the local development setting by running the command for your operating system:

macOS

cat .env.local

What Does This Command Show?

The command prints the full contents of .env.local so you can confirm the setting was saved.

Windows

Get-Content .env.local

What Does This Command Show?

The command prints the full contents of .env.local so you can confirm the setting was saved.

You should see QSTASH_DEV=true as the only line.

Setting Missing or Misspelled?

Run the file creation command again from inside the retry-flaky-step folder.

Check that the filename begins with a dot and ends with .local.

Get help correcting the local environment file.

Before the final check, predict which two pieces of evidence should prove that the SDK and deployment login are ready.

Verify the installed SDK and your authenticated deployment account by running these commands:

npm ls @upstash/workflow
vercel whoami

What Does This Final Check Prove?

The dependency tree should include @upstash/workflow with an installed version. The second command should print the username for your authenticated Vercel account.

Your setup is ready: the Upstash Console is accessible. Your local project has the Workflow SDK plus a deployment login.

Final Check Did Not Pass?

A missing Workflow package means the SDK installation did not complete in the current folder.

A Vercel authentication prompt means the earlier login or sign-up flow did not finish.

Get help interpreting the final check.

✔️ Awesome, I've got everything!

Your Upstash account, local project, Workflow SDK, local development setting, and deployment login are ready. No workflow has been deployed.

ⓧ I'd like to double check the full code

Your .env.local file should contain exactly this line:

QSTASH_DEV=true

This line enables the SDK-managed local QStash development server without placing your production token in the project.

Upstash Console account signed in with a local Node.js project configured to use the Upstash Workflow SDK and deployment credentials.

Your foundation is ready. Next up, you will deploy the three-step workflow and trigger its first successful run.

Deploy the Three-Step Workflow

Your prepared Node.js project can already use the Upstash Workflow SDK. The retry experiments ahead need a clean success record for comparison.

This step creates a three-stage baseline. Its run history gives you evidence that every stage works before one becomes intentionally flaky.

In this step, get ready to:

Define three sequential workflow steps that succeed.
Deploy the workflow as flaky-step-workflow.
Trigger one run to establish a successful baseline.

Define the successful baseline

Each awaited context.run call becomes a separate workflow step. Awaiting the calls one at a time fixes their execution order.

In your editor's file sidebar, create app/api/flaky-step-workflow/route.ts inside the prepared project.
Paste the following handler into app/api/flaky-step-workflow/route.ts:

import { serve } from "@upstash/workflow/nextjs";

export const { POST } = serve(async (context) => {
  // Establish a successful first stage.
  await context.run("step-one", async () => {
    return { status: "step-one-complete" };
  });

  // Keep the future flaky stage successful for the baseline run.
  await context.run("flaky-step", async () => {
    return { status: "flaky-step-complete" };
  });

  // Confirm the workflow reaches its final stage.
  await context.run("step-three", async () => {
    return { status: "step-three-complete" };
  });
});

What does this workflow do?

The serve() function exposes the handler as a workflow endpoint.
Each awaited context.run call finishes before the next call starts.
Each step returns a plain status object that Upstash can persist with the run.
The handler omits step-specific retry settings so this run uses the default behavior.

Save app/api/flaky-step-workflow/route.ts.
Confirm that your editor shows no syntax errors in the file.

Seeing a handler error?

Check that the file sits at app/api/flaky-step-workflow/route.ts. Confirm that the prepared project uses the Next.js adapter import shown above.

Compare all three closing brackets if your editor highlights the final line.

Help me troubleshoot my three-step Upstash Workflow handler.

✔️ Awesome, I've got everything!

Your handler now contains the complete three-step baseline.

ⓧ I'd like to double check the full code

import { serve } from "@upstash/workflow/nextjs";

export const { POST } = serve(async (context) => {
  // Establish a successful first stage.
  await context.run("step-one", async () => {
    return { status: "step-one-complete" };
  });

  // Keep the future flaky stage successful for the baseline run.
  await context.run("flaky-step", async () => {
    return { status: "flaky-step-complete" };
  });

  // Confirm the workflow reaches its final stage.
  await context.run("step-three", async () => {
    return { status: "step-three-complete" };
  });
});

Deploy the workflow endpoint

Upstash needs a public endpoint so it can continue the workflow across requests. The endpoint path gives this workflow the recognizable name flaky-step-workflow.

Publish the prepared project by using the production deployment action already configured in your deployment provider.
Wait for the provider to report a successful production deployment.
Copy the public endpoint that ends in /api/flaky-step-workflow into https://your-domain.example/api/flaky-step-workflow.

Your production deployment now exposes the three-step handler at the endpoint you recorded.

Deployment did not succeed?

Confirm that your deployment provider received the saved route file. Check that the deployment environment still contains the credentials prepared earlier.

Help me diagnose my workflow deployment.

Trigger one successful run

A deployment proves that the endpoint exists. A triggered run proves that Upstash can execute every step through that endpoint.

Your token stays in the environment. The trigger script reads it only at runtime.

In your editor's file sidebar, create trigger-workflow.mjs beside package.json.
Paste the following trigger script into trigger-workflow.mjs:

import { Client } from "@upstash/workflow";

// Reuse the deployment credential already stored in the environment.
const token = process.env.QSTASH_TOKEN;
if (!token) {
  throw new Error("QSTASH_TOKEN is missing.");
}

const client = new Client({ token });

// Start one labeled run against the deployed workflow endpoint.
const { workflowRunId } = await client.trigger({
  url: "[[WORKFLOW_ENDPOINT="https://your-domain.example/api/flaky-step-workflow"]]",
  labels: ["flaky-step-workflow"],
});

console.log(workflowRunId);

What does this trigger do?

The Client reads QSTASH_TOKEN from the prepared environment.
The client.trigger call starts one run at your deployed endpoint.
The labels value makes the run identifiable as flaky-step-workflow.
The script prints the run identifier returned by Upstash.

Save trigger-workflow.mjs.

Before you run the script, do you expect one run identifier or three step identifiers?

Trigger the deployed workflow by running this command:

node trigger-workflow.mjs

What does this command do?

Node.js executes the trigger script once. The script prints the identifier for the complete workflow run.

You will see one identifier beginning with wfr_.

Good progress. That run ID confirms Upstash accepted the trigger.

No run ID in the terminal?

A missing-token error means QSTASH_TOKEN is unavailable to this terminal session. A connection error usually means the recorded endpoint does not match the production deployment.

Help me troubleshoot my workflow trigger.

Finding the correct run can feel fiddly when the console contains older entries. Match the identifier from your terminal to avoid guessing.

Before you inspect the run, do you expect the three step names to appear once each?

Return to the Upstash Console from earlier.
Select the Workflow tab.
Select the workflow labeled flaky-step-workflow.
Select the run whose identifier matches the terminal output.

You will see step-one, flaky-step, then step-three in sequence. Each step shows one successful completion.

Your successful baseline is now visible in the run history. Next, you will make flaky-step fail so you can observe the default retry behavior.

Test the Default Run Retry

The successful baseline proved that your Upstash Workflow can execute all three steps in order. Now you need a controlled failure that exposes what the default retry system repeats.

A rate-limited API can fail during one step. A deliberate failure gives you a clean baseline for the platform's default response.

In this step, get ready to:

Make flaky-step fail deliberately.
Trigger a new workflow run with the default retry settings.
Inspect the newest run's history to discover which work repeats.

What is retry scope?

Retry scope is the boundary that repeats after a failure. It can surround one step or a broader workflow run.

Make the second step fail

The callback inside flaky-step currently completes successfully. For this test, it must fail every time while the surrounding step definitions stay unchanged.

Switch back to the workflow handler open in your local project from earlier.
Locate the context.run call named flaky-step.
Confirm that its callback currently contains the successful logic from the first run.

You should see flaky-step between step-one and step-three. That position confirms you are changing the middle step.

The three step names are your comparison markers. Keep each name unchanged during the failure test.

Replace only the successful callback logic with a thrown error that always stops flaky-step.
Save the open workflow handler.
Redeploy flaky-step-workflow with the same deployment process you used earlier.

You should see the deployment finish without a syntax or build failure. The next invocation now exercises the deliberate failure.

Deployment not completing?

Check that the thrown error sits inside the flaky-step callback.
Restore any surrounding brackets that changed during the edit.

Help me diagnose the workflow deployment failure.

Trigger and inspect the default retry

The failing version gives the default settings a clear test. The run history exposes the boundary around the work that gets another attempt.

Before you trigger the workflow, do you think the history will repeat only flaky-step or a broader part of the run?

Trigger one new workflow run with the same request you used for the successful baseline.

This failure is intentional

The new run reaches flaky-step and records the deliberate failure. This confirms that the updated callback is running.

The retry may take a moment to appear in the history. A brief gap while the run continues is expected.

Return to the flaky-step-workflow run history in the Upstash Console from earlier.
Refresh the run history until the newest run records another attempt.
Select the newest run.
Inspect the entries that occur before each failure of flaky-step.

You should see the workflow run start another attempt under the default settings. step-one appears again before flaky-step fails.

Repeated step-one entries prove that the retry boundary surrounds the workflow run. The default behavior applies the retry to the run instead of isolating it to flaky-step.

That's the baseline captured. Your run history now demonstrates the default run-level retry behavior.

Only seeing one attempt?

Wait briefly for the retry history to update.
Refresh the workflow's run history again.
Confirm that you selected the newest failed run instead of the successful baseline.

Help me find the repeated workflow attempt.

Your default retry baseline is clear. Next, you'll move retry control onto flaky-step so the successful steps can stay outside the retry cycle.

Retry Only the Flaky Step

Your previous run exposed the default retry boundary. When flaky-step failed, Upstash Workflow retried the workflow run.

A step-specific policy keeps completed work from repeating. In this step, you will attach retries to only flaky-step through the third argument of context.run.

In this step, get ready to:

Add a step-specific retry policy to flaky-step.
Redeploy the updated flaky-step-workflow.
Prove that only the failing step receives extra attempts.

Scope retries to the flaky step

Each context.run call can receive an options object as its third argument. Values in that object apply to only that step.

Switch back to the workflow source file from earlier.
Find the context.run call whose first argument is flaky-step.
Keep the deliberate failure callback unchanged.
Add this options object as the third argument of that context.run call:

{ retries: 3 }

What Does This Configuration Do?

The retries field gives this step its own retry count.
The value 3 allows three retries when the callback fails.
The step-one call keeps its existing configuration.
The step-three call keeps its existing configuration.

Save the workflow source file.
Confirm that the flaky-step call now has the options object as its third argument.

Is the retry object in the wrong position?

Place the options object after the callback.
Keep the options object inside the same context.run call.
Remove any step-specific retry object from step-one or step-three.

Help me check the third argument of my flaky step.

Deploy the targeted retry

The console can only test the deployed version of your workflow. Your new retry boundary becomes active after the source change reaches the deployed endpoint.

Use the deployment method from earlier to redeploy flaky-step-workflow.

Your deployment should report that the updated workflow is ready.

Return to the Upstash Console run list from earlier.
Trigger one new run with the same trigger action from the previous test.

You should see a new run added to the workflow's run list.

Don't see a new run?

Confirm that the latest deployment completed successfully.
Confirm that the trigger still targets the deployed flaky-step-workflow endpoint.
Trigger the workflow once more after the deployment becomes ready.

Help me find why my deployed workflow run is missing.

Compare the new run history

Before you inspect the new run, consider which step should carry the extra attempts.

Select the newest run in the workflow's run list.
Select the flaky-step entry.
Select the Config tab for that step.
Confirm that retries displays 3.
Return to the run history.
Confirm that the history shows step-one once.
Confirm that the history shows retries for flaky-step.
Confirm that the history shows step-three once.

You'll see the retry attempts attached to flaky-step.

You'll see step-one run once. You'll also see step-three run once.

You have the retry boundary you wanted. Successful steps now avoid duplicate work when flaky-step needs another attempt.

Your retry policy now follows the step that actually needs it. Next, you'll add flow control to that same step so concurrent runs queue at the correct boundary.

Throttle the Flaky Step

Your Upstash Workflow now keeps all three retries inside flaky-step. A burst of runs can still reach the rate-limited API too quickly.

In this step, you will add flow control to the same context.run configuration. A shared key will queue those calls across every workflow run.

In this step, get ready to:

Deploy a version that throttles flaky-step.
Trigger ten runs of flaky-step-workflow.
Inspect the run histories to confirm that the throttle applies only to flaky-step.

Add flow control to the flaky step

A flow-control key makes separate runs share one set of limits. The parallelism value caps active executions.

The rate value combines with period to control how often executions may start.

Switch back to the workflow source file from earlier.
Find the third argument of context.run for flaky-step.
Replace that configuration object with the code below:

{
  // Keep retries scoped to the flaky step.
  retries: 3,
  // Share one throttle across all workflow runs.
  flowControl: {
    key: "flaky-api",
    parallelism: 1,
    rate: 1,
    period: "10s",
  },
}

What Does This Configuration Do?

The retries value keeps three retries attached to flaky-step.
The flaky-api key groups calls from all workflow runs under one throttle.
The parallelism value allows one active execution at a time.
Together, rate and period permit one execution start in each ten-second window.

Save the workflow source file.
Redeploy flaky-step-workflow by using the same deployment process from earlier.

Your deployment output should confirm that the updated workflow is live. New runs can now receive the step-level throttle.

Deployment Not Succeeding?

Check that flowControl sits beside retries inside the same third argument.
Check that every opening brace in the configuration has a matching closing brace.
Check that the deployed source still contains the exact step name flaky-step.

Help me fix my step-level flow-control configuration.

Fire ten workflow runs

A single run cannot prove that a shared throttle works. A burst makes the queue visible because each flaky-step execution competes for the same key.

The full batch can take several minutes to drain under this limit. You only need the first queued executions for this check.

Return to the trigger method you used for the previous runs.
Trigger flaky-step-workflow ten times in quick succession.
Return to the workflow runs view in the Upstash Console.
Refresh the run list.

You should see ten new run entries grouped close together in time. That burst gives the shared throttle enough pressure to reveal its queue.

Fewer Than Ten Runs Showing?

Refresh the workflow runs view after the final trigger completes.
Count only the entries created after your latest deployment.
Trigger another run for each missing entry.

Help me find my missing workflow runs.

Inspect the shared throttle

The run history shows when each step executes. The step configuration shows which limits produced that timing.

Before you check, do you expect the ten flaky-step executions to start together or spread across time?

Select one of the ten new runs.
Select flaky-step in its history.
Select the Config tab.

The step configuration should show the key flaky-api. It should also show parallelism of 1, rate of 1, period of 10s, and retries of 3.

Return to the workflow runs list.
Compare the flaky-step start times across several new runs.

Their histories should show the flaky-step executions starting at staggered times. Runs beyond the limit remain queued until the shared throttle allows another execution.

Select the FlowControl tab in the Upstash Console.
Find the flaky-api flow-control key.

You should see that the key has a wait list while the burst drains. You have proved that only the flaky API step is throttled across the ten runs.

No Queue Visible?

Confirm that you inspected runs triggered after the flow-control deployment.
Confirm that all ten runs use the same flaky-api key.
Trigger another ten-run burst if the first batch finished before you opened the console.

Help me diagnose why my flaky step is not queuing.

Your flaky step now owns both its retries and its throttle. Next, you will compare the earlier run histories with this queued batch to see exactly what changed.

Compare the Run Histories

Ten queued runs have shown that flow control can protect a rate-limited API across concurrent executions in your Upstash Workflow. The final question is whether those controls stayed attached to the one flaky step.

The run history in the Upstash Console gives you the evidence. This side-by-side comparison will show how the third argument of context.run changes retry scope.

In this step, get ready to:

Compare default retry behavior with step-only retry behavior.
Trace the shared queue across the ten flow-controlled runs.
Confirm unaffected steps execute only once.

Compare the retry scopes

Retry scope determines how much work repeats after a failure. The two earlier failure tests expose the difference.

The earlier retry runs can be fiddly to spot beneath the ten newer runs. Their execution patterns identify them.

Switch back to the Upstash Console run history from earlier.
Select the earlier run where flaky-step deliberately fails under the default retry settings.
Inspect the execution sequence after the failure.

You should see the default behavior retry the workflow run. This history shows that the retry scope extends beyond flaky-step.

Return to the workflow's run list.
Select the step-only retry test run.
Inspect the execution count for each step.

You should see retry attempts attached to flaky-step. You should see step-one and step-three execute once each.

Why does this comparison matter?

The third argument of context.run scopes the retry configuration to flaky-step. The histories prove that the other two steps do not inherit the retry count.

Trace the flow-controlled queue

Flow control governs when each flaky-step execution may begin. The shared key coordinates that limit across all ten runs.

Return to the ten flow-control test runs.
Select one run that reached flaky-step.
Inspect where the run waits before that step executes.

You should see the run wait at flaky-step under the shared flaky-api key.

Return to the ten-run history.
Select a second run that reached flaky-step.
Compare its execution timing with the first run.

You should see both runs coordinated by the same queue. Only one execution proceeds at a time.

The shared settings keep parallelism at 1. They release one execution every 10 seconds.

You have now proved that the queue protects the sensitive step without wrapping the other two steps.

Can't distinguish the queued runs?

Choose two runs triggered close together.
Compare the history entries around flaky-step.
Look for waiting or throttling attached to that step.

Ask for help interpreting the evidence: Help me compare these Upstash Workflow run histories and identify where flow control is applied.

Confirm the full comparison

A complete comparison separates the successful baseline from the three behavior tests. This final pass connects each history to one clear claim.

Before the final check, where do you expect repeated work to appear across the four histories?

Return to the initial successful run.
Check the execution count for every step.
Return to the default retry test.
Inspect the execution sequence around the deliberate failure.
Return to the step-only retry test.
Inspect each step's execution count.
Return to the ten flow-controlled runs.
Inspect where queued execution collects across the runs.

What should I see?

Initial success: step-one, flaky-step, and step-three each complete once.
Default retry: the deliberate failure triggers retry behavior for the workflow run.
Step-only retry: the retry count of 3 applies to flaky-step. The other two steps run once.
Flow-controlled runs: all ten runs queue at flaky-step under flaky-api. The shared settings keep parallelism at 1. They release one execution every 10 seconds.

Strong finish. Your run history now proves that the retry count and queue belong to flaky-step.

Secret mission

Audit Retry Isolation Under Load

Turn your existing run histories into a production-readiness audit. Trace one queued run to flaky-step. Use the evidence to define an alert rule for the rate-limited dependency.

Clean Up Your Resources

Choose whether to keep your Upstash Workflow available, pause your testing, or remove the hosted resources entirely. Your exact ongoing cost depends on the Upstash plan and hosting plan attached to your deployment.

Resources you used:

Your deployed flaky-step-workflow workflow.
Your test histories in the Upstash Console.
The hosting deployment that serves your workflow endpoint.

Keep everything running

No action is needed. Choose this option if you want to continue testing step-level retries or flow control.

Keep the hosting deployment active.
Keep flaky-step-workflow available in the Upstash Console.
Use the existing histories when you want to revisit the retry comparison.

Pause - I'll come back to this later

Pause new test activity while keeping your comparison evidence intact. The workflow endpoint remains deployed under your existing hosting plan.

Stop sending requests to the deployed workflow endpoint.
Leave flaky-step-workflow unchanged in the Upstash Console.
Leave the hosting deployment unchanged.
Resume testing later with the deployed endpoint from earlier.

Delete - I don't want to use this again

Remove the workflow plus its hosting deployment when you have finished testing. This takes the public workflow endpoint offline.

Deletion is permanent

This cleanup is intentionally final. The run history you used for your comparison may no longer be available after you remove the workflow.

Save any screenshots of the successful run or retry comparisons that you want to keep.
Return to the flaky-step-workflow page in the Upstash Console.
Remove flaky-step-workflow using the deletion control on its workflow page.
Confirm that flaky-step-workflow no longer appears in the Upstash Console.
Return to the hosting provider project page that contains the deployment from earlier.
Remove the hosting deployment using that provider's project removal flow.
Visit the deployed workflow URL from earlier.

The deployed URL should no longer accept workflow requests. Your workflow should no longer appear in the Upstash Console.

Nice Work!

You did it. Your Upstash Workflow now gives flaky-step its own resilience policy.

You've learned how to:

Deploy a three-step workflow. Trigger it to confirm that each step succeeds once.
Reproduce default retry behavior when flaky-step fails. Move 3 retries into the third context.run argument so step-one plus step-three each run once.
Apply step-level flow control to flaky-step. Trigger ten runs to watch them queue under flaky-api. Compare the run histories to prove that the flaky step owns both controls.
Secret Mission: Complete an optional challenge to push your workflow skills further.

Ready to quiz yourself?