Get Alerts for Cloudflare Worker Errors

Deploy a Worker that sends chat or webhook alerts when production errors recur.

Introduction

30 Second Summary

A website can break while the person who built it carries on unaware. Each silent failure sends another visitor into the same dead end.

In this project, you will deploy a Cloudflare Worker that reports failures through Workers Issues. An automation will alert your chat channel or webhook when an issue reaches three occurrences.

What You'll Build

You will refresh a broken Worker route until your chosen destination receives an alert for the failure.

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

A live Worker URL that you can open in your browser to prove the deployment is online.
Visible failure reports for uncaught exceptions. Handled errors also appear with occurrence counts.
A threshold alert that runs after the third occurrence. Its successful run ends with a message in your chat channel or webhook destination.
Secret Mission: An optional challenge to push your monitoring skills further.

Are there any prerequisites?

You need a Cloudflare account with a chat channel or HTTPS webhook endpoint ready. Your computer needs Node.js with npm plus Wrangler 4.134.0 or later.

Before We Start

A Worker alert can only be tested after your machine can deploy to the right Cloudflare Workers account.

This step prepares your account first. You will also set up Node.js plus Wrangler so the next step can focus on your Worker.

In this step, get ready to:

Create or access a Cloudflare account.
Confirm Node.js plus npm are available.
Install Wrangler version 4.134.0 or later.

Create or access your Cloudflare account

Your account holds the Worker you deploy later. Choose the tab that matches your current situation.

✔️ I already have a Cloudflare account

Your existing account is enough for this project. You only need to confirm that its dashboard is available.

Visit the Cloudflare dashboard in your browser.
Complete your usual sign-in process.
Confirm that you can see your account page in the dashboard.

ⓧ I need to create an account

Your password stays inside Cloudflare's sign-up form. You never paste it into the terminal.

Visit the official Cloudflare sign-up page in your browser.
Enter your email address in the Email field.
Enter a password in the Password field.
Select Create Account.

Cloudflare sends a verification message to the email address you entered.

Open the verification message from Cloudflare.
Use the link in the message to verify your email address.
Return to the Cloudflare dashboard.
Confirm that you can see your account page.

Your dashboard now gives you a home for the Worker you create in the next step.

Check Node.js

Wrangler runs through Node.js. The Node.js installer also includes npm for installing command-line packages.

Press Cmd+Space on macOS or the Windows key on Windows to open system search.
Search for your terminal application.
Select the terminal application shown in the results.
Check the installed Node.js plus npm versions by running:

node --version
npm --version

The terminal prints one version number for Node.js. It prints another version number for npm.

✔️ I see Node.js and npm versions

Both tools are ready. Keep this terminal open for the Wrangler setup.

ⓧ A command is not found

Node.js needs to be installed before Wrangler can run. The LTS release is the stable choice for this setup.

Visit the official Node.js download page.
Download the LTS installer for your operating system.
Run the downloaded installer.
Complete the installer using its default options.
Close your terminal after the installation completes.
Reopen your terminal through system search.
Check both tools again by running:

node --version
npm --version

You should now see a version number on each line.

Still missing Node.js?

Restart your computer if the installer completed but the terminal still cannot find Node.js. This refreshes the command paths available to new terminal sessions.

Use this help link if either command still fails. Help me troubleshoot my Node.js installation.

Install and authenticate Wrangler

Wrangler is the command-line tool that deploys your code to Cloudflare Workers. This project needs version 4.134.0 or later.

Check whether Wrangler is already installed by running:

wrangler --version

The terminal either prints your Wrangler version or reports that the command is unavailable.

✔️ I see the required version or higher

Wrangler is ready if the reported version is 4.134.0 or later.

ⓧ I see an older version

The installed Wrangler version needs an update before you continue.

Install the latest Wrangler release by running:

npm install -g wrangler

npm updates the globally available Wrangler command.

Confirm the updated version by running:

wrangler --version

Continue when the reported version is 4.134.0 or later.

ⓧ The command is not found

Wrangler needs to be installed before your terminal can use its commands.

Install Wrangler globally by running:

npm install -g wrangler

The global installation makes the Wrangler command available from any terminal folder.

Confirm the installed version by running:

wrangler --version

You should see version 4.134.0 or later.

Wrangler uses OAuth to connect with your Cloudflare account. The approval happens in your browser without exposing your password in the terminal.

Start the browser-based authorization flow by running:

npx wrangler login --device

Wrangler prints a verification URL plus a short code. It also attempts to open the approval page in your browser.

Copy the printed verification URL into your browser if the page does not open automatically.
Confirm that the browser shows the same code as your terminal.
Approve Wrangler's access to your Cloudflare account.
Return to your terminal after the browser confirms the authorization.

Before you run the final check, what account details do you expect Wrangler to show?

Verify Wrangler's authenticated account by running:

npx wrangler whoami

You should see your authenticated Cloudflare account details in the terminal.

Wrangler not connecting?

If the browser does not open, use the verification URL printed in your terminal. Approve the request before its code expires.

If the final check does not show your account, repeat the device login flow. Help me troubleshoot Wrangler authentication.

That is the preparation complete. Wrangler can now reach your Cloudflare account from the terminal.

Your account plus local tools are ready. Next up, you will create the Worker that powers your alert.

Deploy an Observable Worker

A production alert needs a live app with error capture enabled before a failure happens. Workers Issues only processes traffic that arrives after you turn it on.

You will scaffold a small Cloudflare Worker with your authenticated Wrangler setup. Its configuration enables Workers Issues before the first production request reaches it.

In this step, get ready to:

Scaffold a JavaScript Worker named worker-issues-alert-demo.
Enable Workers Issues in the Wrangler configuration.
Deploy the Worker to its assigned workers.dev URL.

Create the Worker project

The C3 scaffolder creates a starter Worker with a source file and Wrangler configuration. The generated project also includes a local Wrangler dependency that supports your deployment workflow.

Press Cmd+Space on macOS or the Windows key on Windows to open your search bar.
Type Terminal and press Enter to open it.
Move to your Desktop by running this command:

cd ~/Desktop

Why start on your Desktop?

This command gives the new project a predictable location. You can find the worker-issues-alert-demo folder on your Desktop after the scaffold finishes.

The first scaffold can take a few minutes while npm downloads the template and installs its dependencies.

Enter y if npm asks for permission to install create-cloudflare.
Scaffold the JavaScript Worker without deploying it by running this command:

npm create cloudflare@latest worker-issues-alert-demo -- --type=hello-world --lang=js --no-deploy --accept-defaults

What does this command do?

The hello-world template creates a small Worker that returns a visible response.
The --lang=js option selects JavaScript for the starter source.
The --no-deploy option keeps the Worker local until its monitoring configuration is ready.
The --accept-defaults option accepts the remaining scaffold defaults.

That scaffold gives you the local foundation for the alerting project. The Worker stays undeployed until its Issues setting is in place.

Move into the generated worker-issues-alert-demo folder by running this command:

cd worker-issues-alert-demo

Why change folders?

Wrangler reads the configuration in the current folder. Moving into worker-issues-alert-demo makes every following command target this Worker.

Confirm the project files exist by running this command:

ls

What should I see?

You should see package.json, src, and wrangler.jsonc in the output. These files confirm that C3 created a local Wrangler project.

Project folder missing?

Check that the scaffold command finished before you changed folders. If it stopped during dependency installation, return to your Desktop and run the scaffold command again.

Make sure the folder name is exactly worker-issues-alert-demo.

Help me fix the Worker scaffold.

Enable Workers Issues

The wrangler.jsonc file controls what Wrangler deploys. Adding observability.issues.enabled ensures production failures can be grouped into issues after deployment.

Choose your platform below to open wrangler.jsonc in a plain-text editor.

macOS

Click Finder in the Dock.
Select Desktop in the Finder sidebar.
Double-click the worker-issues-alert-demo folder.
Control-click wrangler.jsonc.
Select Open With.
Select TextEdit.

Windows

Click File Explorer in the taskbar.
Select Desktop in the left sidebar.
Double-click the worker-issues-alert-demo folder.
Right-click wrangler.jsonc.
Select Open with.
Select Notepad.

Select the full contents of wrangler.jsonc by pressing Cmd+A on macOS or Ctrl+A on Windows.
Replace the selected configuration by pasting this code:

{
  // Keep the deployed Worker name explicit
  "name": "worker-issues-alert-demo",
  // Point Wrangler at the starter Worker
  "main": "src/index.js",
  // Pin runtime behavior to the project date
  "compatibility_date": "2026-10-30",

  // Persist Worker logs
  "observability": {
    "enabled": true,
    // Group production failures into Issues
    "issues": {
      "enabled": true
    }
  }
}

What does this configuration do?

The name value gives the deployed Worker its worker-issues-alert-demo identity.
The main value points Wrangler to the generated src/index.js source file.
The compatibility_date value pins the runtime behavior used by this project.
The nested issues.enabled value turns on failure grouping for new production traffic.

Save wrangler.jsonc by pressing Cmd+S on macOS or Ctrl+S on Windows.

✔️ Awesome, I've got everything!

Great. Double check that wrangler.jsonc is saved before validating the configuration.

ⓧ I'd like to double check the full code

Compare your complete wrangler.jsonc file with this version:

{
  // Keep the deployed Worker name explicit
  "name": "worker-issues-alert-demo",
  // Point Wrangler at the starter Worker
  "main": "src/index.js",
  // Pin runtime behavior to the project date
  "compatibility_date": "2026-10-30",

  // Persist Worker logs
  "observability": {
    "enabled": true,
    // Group production failures into Issues
    "issues": {
      "enabled": true
    }
  }
}

Before you validate the file, do you think Wrangler will accept the new Issues setting?

Return to the terminal from earlier.
Validate the saved configuration without publishing the Worker by running this command:

npx wrangler deploy --dry-run

What does the dry run prove?

The --dry-run option asks Wrangler to build the Worker without uploading it. A successful build confirms that Wrangler can read the edited wrangler.jsonc file.

You should see Wrangler build the Worker without reporting a configuration error. Your Issues setting is ready to be deployed.

Configuration not accepted?

Compare every brace and comma in wrangler.jsonc with the full-code tab. A missing closing brace can prevent Wrangler from reading the file.

Confirm that issues sits inside observability.

Help me fix my Wrangler configuration.

Take the Worker live

The dry run proves that the project can build with Issues enabled. A real deployment applies that configuration to your Cloudflare account and assigns the Worker a public address.

Select your Cloudflare account if Wrangler asks which authenticated account should receive the Worker.
Apply the saved configuration by running this deployment command:

npx wrangler deploy

What does this deployment do?

Wrangler builds the generated src/index.js Worker.
Wrangler uploads the Worker to your Cloudflare account.
Wrangler applies the observability.issues.enabled setting from wrangler.jsonc.
Cloudflare assigns the deployment a public workers.dev URL.

You should see deployment output followed by the assigned workers.dev address. That address is the production endpoint for this Worker.

Record the assigned address here: https://worker-issues-alert-demo.your-subdomain.workers.dev.

Before you open the address, what response do you expect from the generated starter Worker?

Switch back to your browser.
Paste https://worker-issues-alert-demo.your-subdomain.workers.dev into the address bar.
Press Enter.

You should see Hello World! in the browser. This confirms that worker-issues-alert-demo is deployed and reachable through its assigned URL.

Live Worker not loading?

Confirm that you copied the production workers.dev address from the deployment output. A preview address can point to a different Worker version.

If the first deployment shows a 523 page, wait about a minute before refreshing the same address.

Help me debug my Worker deployment.

Your observable Worker is live at its workers.dev URL. Next, you will add a route that fails on purpose so Issues has a real production error to capture.

Trigger an Uncaught Error

Your Cloudflare Workers service is live. Workers Issues now needs a real production failure to capture.

A dedicated /uncaught-error route gives you a controlled failure without disturbing the healthy path. You will publish that change with Wrangler.

In this step, get ready to:

Add a route that throws an uncaught exception.
Deploy the updated Worker to its existing live URL.
Visit the failing route to generate a production error.

Add the failing route

An uncaught exception escapes the Worker without producing a normal response. This gives Workers Issues a production failure to record.

Return to the editor that contains your worker-issues-alert-demo project.
Open the Wrangler configuration file from the editor's file sidebar.
Find the main key to identify the Worker entry file.
Open the referenced entry file from the editor's file sidebar.
Place your cursor at the start of the existing fetch handler before its current response logic.
Add the intentional failure branch by pasting this code:

if (new URL(request.url).pathname === "/uncaught-error") {
  // Leave this exception uncaught so Workers Issues can record it.
  const error = new Error("Intentional uncaught Worker error");
  throw error;
}

What does this code do?

The path check limits the deliberate failure to /uncaught-error.
The new Error object describes the controlled failure.
The throw statement lets the exception escape the fetch handler. Workers Issues can record the failed invocation.

Save the Worker entry file by pressing Cmd+S (macOS) or Ctrl+S (Windows).
Confirm the editor no longer shows an unsaved-change indicator on the entry file.

Seeing an error in the editor?

Make sure the branch sits inside the existing fetch handler where request is available. Keep the Worker's existing healthy response logic below the new branch.

Check that the braces around the new path condition match the snippet. A missing brace can stop the next deployment.

Help me place the uncaught-error branch inside my Worker fetch handler.

✔️ Awesome, I've got everything!

Your Worker entry file now contains the dedicated failure branch. Double check that the file is saved before deploying it.

ⓧ I'd like to double check the full code

Compare the complete /uncaught-error branch against the code inside your fetch handler:

if (new URL(request.url).pathname === "/uncaught-error") {
  // Leave this exception uncaught so Workers Issues can record it.
  const error = new Error("Intentional uncaught Worker error");
  throw error;
}

Deploy the updated Worker

The new route currently exists only in your local project. Deploying replaces the live Worker code with this saved version.

Switch back to the terminal panel you used for the first deployment.
Deploy the updated Worker by running:

npx wrangler deploy

What does this command do?

Wrangler uploads the saved Worker code to Cloudflare. Cloudflare then updates the existing worker-issues-alert-demo deployment.

You should see deployment confirmation followed by the assigned live URL. Your controlled failure route is now live on the deployed Worker.

Deployment not completing?

Confirm the terminal is still inside the worker-issues-alert-demo project. Wrangler needs the configuration file from that folder.

If Cloudflare asks you to authenticate again, complete the sign-in flow from the earlier setup before retrying the deployment.

Help me debug why my Worker deployment is failing.

Trigger the production error

A browser request to the live route becomes production traffic for the deployed Worker. The request gives Workers Issues a new failure event to process.

Before you visit the route, do you expect the Worker to return its healthy response or fail the request?

Switch back to the browser tab showing the live Worker URL from the previous step.
Visit the same live URL with /uncaught-error appended to its address.

You should see an HTTP 500 error in the browser. That deliberate failure is the win for this step.

Why does this count as success?

The route throws before the Worker can return a normal response. The failed invocation creates the uncaught-error event that Workers Issues can group into an issue.

Workers Issues processes traffic received after monitoring is enabled. This request supplies the production failure you need for the next step.

Still seeing the healthy response?

Confirm the browser address ends with /uncaught-error exactly. The path check only runs for that route.

Confirm the deployment completed after you saved the entry file. An older deployment still returns the original healthy response.

Help me work out why my live uncaught-error route is not returning a 500 error.

Your deployed Worker has emitted its first monitored failure. Next, you will find that occurrence in Workers Issues and inspect how Cloudflare grouped it.

Inspect the Uncaught Issue

Your deployed Worker now returns a 500 response from /uncaught-error. The browser proves the request failed, but production monitoring still needs to turn that moment into something you can track.

In this step, you'll use Workers Issues to find the uncaught exception in the Cloudflare dashboard. You'll confirm its occurrence count so you know the failure reached monitoring.

In this step, get ready to:

Open the Issues overview in the Cloudflare dashboard.
Locate the issue created by the uncaught exception.
Confirm the issue displays an occurrence count.

Check production monitoring

Workers Issues records each detected failure as an occurrence. Related occurrences are grouped into one issue.

Open the official Cloudflare Issues overview.
Sign in to the Cloudflare account that owns worker-issues-alert-demo if prompted.

You should see the Issues overview for your Cloudflare account.

Inspect the grouped failure

The occurrence count shows how many detected failure events belong to the issue. Repeated failures increase the count on the same grouped issue.

Before you inspect the list, do you think the request that returned 500 was captured after Issues was enabled?

Scan the Issues overview for the uncaught exception from worker-issues-alert-demo.
Read the occurrence count shown with the issue.

You should see an issue for the uncaught exception from worker-issues-alert-demo. Its occurrence count should be at least 1.

That confirms your monitoring works: the uncaught failure now has a trackable issue.

Issue not appearing?

Confirm you signed in to the Cloudflare account that owns worker-issues-alert-demo.
Refresh the Issues overview.
Return to the browser tab with the Worker URL if the overview remains empty.
Reload the /uncaught-error route once.
Return to the Issues overview.
Refresh the overview again.

You should now see the uncaught exception grouped into an issue with an occurrence count.

Help me work out why my uncaught Worker exception is missing from Workers Issues.

Your uncaught failure is visible in the Cloudflare dashboard. Next, you'll capture an error that the Worker handles itself.

Report a Handled Error

The uncaught exception is now visible in Workers Issues. Your Worker already reports failures that escape its code.

Applications often catch failures so they can keep serving a response. Those failures still need attention.

In this step, you'll send a caught failure to console.error(). You will then confirm that it becomes a separate issue.

In this step, get ready to:

Add a /handled-error route with a caught failure.
Report the caught failure through console.error().
Verify the handled failure appears in Workers Issues.

Add the handled error route

A handled route captures its own failure before the error escapes the request. Reporting that captured error preserves visibility while the route keeps control of its response.

How does the route handle the error?

The route creates a failure inside its error-handling block.
The handler captures the failure before it escapes the request.
The handler passes the captured error to console.error().
The route returns a normal response after handling the failure.

In your worker-issues-alert-demo project, select the Worker source file that contains the /uncaught-error route.
Add a /handled-error route below the existing /uncaught-error route using the four-part structure above.
Save the Worker source file.

Return to the terminal for worker-issues-alert-demo.
Deploy the updated Worker with the same Wrangler deployment command you used earlier.

You should see Wrangler confirm that the deployment succeeded. The deployment should continue using your existing workers.dev address.

Deployment not succeeding?

Check that the new route sits inside the same routing structure as /uncaught-error.
Check the brackets around the new error-handling block.
Confirm that the caught error is passed to console.error().

Help me debug the handled error route in my Worker.

Trigger the handled error

Before you visit the new route, predict whether the browser will show its handled response or the uncaught 500 result from earlier.

Return to the browser tab for your live Worker.
Replace /uncaught-error at the end of the address with /handled-error.
Load the updated address.

You should see the normal response from your handled route. This proves the error-handling path kept control of the request.

Why does the handled error still matter?

The route catches the failure before it becomes an uncaught exception. Calling console.error() gives Workers Issues a reported failure to group.

This gives you visibility into problems that your application handles without crashing the request.

Verify the handled issue

Before you refresh the dashboard, predict whether the caught failure will appear beside the uncaught exception.

Return to the Issues page in the Cloudflare dashboard from earlier.
Refresh the Issues page.

You should see the uncaught exception plus the handled error as separate issues. Each issue should display an occurrence count.

Your handled failure is now visible through console.error(). This confirms Workers Issues can surface both failure paths.

Handled error missing from Issues?

Visit the /handled-error route one more time.
Refresh the Issues page again.
Check that the deployed route passes the captured error to console.error().

Help me find why my handled Worker error is missing from Workers Issues.

That's a useful upgrade: your Worker now reports escaped crashes plus caught failures. Next, you'll create the automation that turns repeated occurrences into an alert.

Create an Issue Alert Automation

Your Worker now reports failures to Workers Issues. The dashboard groups each failure with an occurrence count.

An issue hidden in a dashboard can still be missed. You will connect it to a webhook with an occurrence-threshold automation.

In this step, get ready to:

Configure an occurrence threshold of 3.
Create the worker-issues-webhook destination.
Enable the worker-issues-alert automation.

Define when the alert fires

The occurrence threshold controls when a matching issue is handed to its destination. A value of 3 gives this project a short trigger point for the alert test.

Return to the Cloudflare dashboard Issues page from earlier.
Select Automations.
Select Add automation.

You should see a form for configuring the trigger and destination.

Enter worker-issues-alert as the automation name.
Select Occurrence threshold as the trigger type.

A field for the occurrence count is now available.

Enter 3 in the threshold field.

You should see the trigger configured for an issue occurrence count of 3.

How the threshold behaves

An occurrence-threshold automation runs once when an issue crosses the configured count. Later occurrences do not run the same automation again.

Connect the webhook destination

A Generic Webhook destination sends the matching issue event to your HTTPS endpoint.

Protect your webhook credentials

The next fields accept live credentials. Paste them only into Cloudflare's destination form.

Keep the webhook URL out of screenshots. Keep the secret out of project files or chat messages.

Select the option to create a destination in the destination section.
Select Generic Webhook as the destination type.

You should see fields for the destination name and HTTPS endpoint.

Enter worker-issues-webhook in the destination name field.

The destination now has the project-specific name used by your automation.

Paste your webhook URL into the HTTPS endpoint field.

The endpoint field now points to your alert receiver.

Enter the webhook secret required by your endpoint.
Select Create destination.

That is the sensitive setup handled: worker-issues-webhook is now selected without placing its credential in your Worker code.

Destination not created?

Confirm that your endpoint uses HTTPS.
Re-enter the webhook secret required by your endpoint.
Check that worker-issues-webhook is still present in the destination name field.

Help me troubleshoot the webhook destination setup.

Publish the alert automation

The Enabled control decides whether the trigger can hand matching issues to your destination. Saving with this control on arms the alert rule.

Before you save it, what status do you expect to see beside the automation on the Automations page?

Turn on Enabled.
Select Create.

Cloudflare saves the alert rule with its destination and threshold.

Return to the Automations page from Issues.

You should see worker-issues-alert listed with an enabled status.

The destination should read worker-issues-webhook.

The trigger should show an occurrence threshold of 3.

That is the alert path armed: your enabled rule now connects matching issues to worker-issues-webhook at occurrence 3.

Automation missing or disabled?

Confirm that Enabled is turned on in worker-issues-alert.
Confirm that the occurrence threshold is 3.
Confirm that the selected destination is worker-issues-webhook.

Help me troubleshoot the Issues automation configuration.

Your alert automation is ready. Next, you will create enough failures to cross its trigger point and confirm that the webhook receives the alert.

Trigger and Confirm the Alert

Your Workers Issues automation is enabled with an occurrence threshold of 3. It remains unproven until a real issue crosses that threshold.

In this step, you will trigger enough uncaught failures to launch the automation. You will confirm that Cloudflare delivered the alert to your webhook destination.

In this step, get ready to:

Raise the /uncaught-error issue count to at least 3.
Confirm that worker-issues-webhook received the issue alert.
Verify that the worker-issues-alert automation run succeeded.

Raise the occurrence count to three

An occurrence threshold counts repeated instances of the same grouped issue. Each fresh request to /uncaught-error adds another occurrence for the uncaught exception.

Before you refresh the route, do you expect the browser response to change as the occurrence count rises?

Return to the browser tab from earlier that shows /uncaught-error.
Refresh the page once.

You should see another 500 response. The request still reaches the failing route even though the browser only shows an error.

Return to the Cloudflare Issues page from earlier.
Refresh the Issues page.
Select the uncaught-exception issue created by /uncaught-error.
Repeat the route refresh when the occurrence count remains below 3.
Repeat the Issues page refresh after each new failure.

You should see an occurrence count of at least 3. That is the trigger point reached: the issue now satisfies your automation's threshold.

Count still below three?

Return to the live /uncaught-error route.
Refresh the route again.
Return to the Cloudflare Issues page.
Refresh the issue details to load the latest occurrence count.

Help me understand why my Workers Issues occurrence count is not increasing.

Confirm the webhook alert

The webhook destination provides the first proof that the issue left Cloudflare. Finding the delivery can be a little fiddly because webhook receivers use different labels for incoming request logs.

Return to the app or service that owns the webhook URL from earlier.
Open the incoming request history for that webhook URL.
Refresh the incoming request history.
Select the newest delivery received after the threshold crossing.

You should see a new issue alert at the webhook receiver. The delivery proves that worker-issues-webhook received the uncaught-failure notification.

The alarm has now reached a destination where you can act on it. Your Worker failure is no longer confined to the Cloudflare dashboard.

Why does the threshold alert once?

The occurrence threshold starts one automation run when the issue reaches 3. Later occurrences increase the issue count without making this threshold automation run for every event.

No webhook delivery?

Refresh the webhook receiver's incoming request history.
Confirm that you are checking the receiver connected to worker-issues-webhook.
Return to the Cloudflare Issues page to confirm the occurrence count is at least 3.

Help me troubleshoot why my webhook destination did not receive the Workers Issues alert.

Verify the automation run

The webhook delivery proves the destination side worked. Cloudflare's automation run record provides an independent confirmation that the trigger completed successfully.

Before you check the run history, which status do you expect after the webhook received the alert?

Return to the Cloudflare Automations page from earlier.
Select worker-issues-alert.
Open the most recent automation run.

You should see the most recent run marked succeeded.

That closes the alert loop. Your Worker can now turn a repeated production failure into a delivered webhook alert.

Run not showing succeeded?

Refresh the automation run history.
Confirm that the selected automation is worker-issues-alert.
Return to the Cloudflare Issues page to confirm the uncaught-exception count is at least 3.
Check that the webhook receiver shows the new issue alert.

Help me diagnose why my Workers Issues automation run is missing or unsuccessful.

Secret mission

Build a Repeat-Failure Playbook

Your alert proved that the first threshold crossing reaches your webhook. Trigger the same failure again to test what changes, then turn the evidence into an incident triage playbook.

Clean Up Your Resources

The open-beta terms used for this project made Workers Issues free during the project. You can keep the setup active, pause the automation, or delete the resources.

Your webhook provider may charge separately while the destination remains active.

Resources you used:

Deployed Cloudflare Worker named worker-issues-alert-demo.
Enabled Issues automation named worker-issues-alert.
Cloudflare webhook destination named worker-issues-webhook.
Any dedicated webhook URL, secret, or token created for this alert.
Local Wrangler project folder named worker-issues-alert-demo.

Keep everything running

No action is needed. Choose this option if you are still using the alert or want to adapt it later.

Leave worker-issues-alert-demo deployed.
Leave worker-issues-alert enabled.
Keep worker-issues-webhook available for future alerts.
Store any dedicated webhook credential in your provider's secure credential store.
Keep the local worker-issues-alert-demo folder for future changes.

Pause - I'll come back to this later

Pause the automation to stop future alert deliveries. Your deployed Worker remains available when you return.

Return to the Automations page from earlier.
Select worker-issues-alert.
Turn off the automation's enabled setting.
Confirm the automation shows a disabled status.
Leave worker-issues-webhook unchanged.
Leave worker-issues-alert-demo deployed.

Your existing issues remain visible while the disabled automation stops sending new alerts.

Delete - I don't want to use this again

Permanent deletion is a big step. This path disables the automation before removing its connected resources.

Return to the Automations page from earlier.
Select worker-issues-alert.
Turn off the automation's enabled setting.
Confirm the automation shows a disabled status.

The disabled automation can no longer send alerts through its destination.

Return to the destination management area from earlier.
Select worker-issues-webhook.
Use the destination page's permanent deletion control.
Confirm worker-issues-webhook no longer appears in the destination list.

Deleting the destination removes the Cloudflare connection to your webhook endpoint.

Return to the Cloudflare dashboard page for worker-issues-alert-demo from earlier.
Select the Worker's settings area.
Use the Worker's permanent deletion control.
Confirm worker-issues-alert-demo no longer appears in your Worker list.

The deployed Worker no longer receives requests after deletion.

A dedicated webhook URL, secret, or token may continue working outside Cloudflare. Revoke it when you created it specifically for this project.

Return to the provider that supplied the dedicated webhook credential.
Use the provider's documented credential controls to revoke the project credential.
Confirm the provider shows the credential as revoked or inactive.

Your local folder may be stored in a location specific to your machine. Its exact name identifies the correct Wrangler project.

macOS

Use macOS file search to locate worker-issues-alert-demo.
Confirm the result contains your local Wrangler project files.
Delete the selected worker-issues-alert-demo folder using your Mac's permanent deletion controls.
Search for worker-issues-alert-demo again.
Confirm no matching project folder remains.

Windows

Use Windows file search to locate worker-issues-alert-demo.
Confirm the result contains your local Wrangler project files.
Delete the selected worker-issues-alert-demo folder using your PC's permanent deletion controls.
Search for worker-issues-alert-demo again.
Confirm no matching project folder remains.

Nice Work!

You did it! Your deployed Cloudflare Worker now turns production failures into a working webhook alert through Workers Issues.

You've learned how to:

Deploy a live Cloudflare Worker with Workers Issues enabled for production traffic.
Trigger an uncaught exception that returns a 500 error. Report a handled failure through console.error(). Confirm both failures appear on the Issues page with occurrence counts.
Set an occurrence threshold of 3 on an enabled automation. Send the matching issue to the webhook destination. Confirm the alert arrives. Verify the automation run succeeds.
Secret Mission: complete the optional project extension to sharpen your failure-alerting workflow.

Ready to quiz yourself?