JavaScript Worker error Event

Beginner
⏱️ 10 min read
📚 Updated: Jul 2026
🎯 5 Examples
🚀 5 Try-it labs
Baseline Widely available
Instance event

What You’ll Learn

The error event of the Worker interface fires when an error occurs in the worker. Learn onerror vs addEventListener("error"), how it differs from the message event, and how to recover—with five examples and try-it labs.

01

Kind

Instance event

02

Name

error

03

Type

Event (ErrorEvent)

04

Handler

onerror

05

vs

message

06

Status

Baseline widely

Introduction

Workers run on another thread. If their script throws, the main page does not get a normal JavaScript exception in your postMessage call. Instead, the Worker object fires an error event.

Attach a handler early—before work starts—so you can show a friendly message, log details, and optionally terminate() a broken worker.

💡
Beginner tip

Successful replies use the message event (event.data). Failures use the error event. Listen for both when you depend on a worker.

Understanding the Worker error Event

An instance event on Worker that fires when an error occurs in the worker.

  • Event name"error".
  • Handler propertyworker.onerror.
  • Listenerworker.addEventListener("error", handler).
  • Event type (MDN) — a generic Event; browsers often provide ErrorEvent fields such as message.
  • Baseline Widely available on MDN (since July 2015); available in Web Workers except Service Workers.

📝 Syntax

Use the event name in methods like addEventListener(), or set an event handler property.

JavaScript
addEventListener("error", (event) => { })

onerror = (event) => { }

Event type

A generic Event (per MDN). In practice you may also read ErrorEvent properties such as message.

Typical pattern

JavaScript
const myWorker = new Worker("worker.js");

myWorker.onerror = (event) => {
  console.log("There is an error with your worker!");
  console.log(event.message); // often available
};

⚡ Quick Reference

GoalCode / note
Handler propertyworker.onerror = (e) => { … }
addEventListenerworker.addEventListener("error", handler)
Read messageevent.message (when ErrorEvent)
RecoverLog, notify UI, optionally terminate()
MDN statusBaseline Widely available (since July 2015)

🔍 At a Glance

Four facts to remember about the Worker error event.

Fires
on failure

In the worker

Listen
onerror

Or addEventListener

≠ message
different

Not event.data

Baseline
widely

Since Jul 2015

Examples Gallery

Examples follow MDN Worker: error event. Labs use blob workers that throw so you can see the handler fire.

📚 Getting Started

Attach handlers the two standard ways.

Example 1 — onerror Handler (MDN Idea)

Set onerror on the Worker object.

JavaScript
const myWorker = new Worker(url);

myWorker.onerror = (event) => {
  console.log("There is an error with your worker!");
  event.preventDefault();
};
Try It Yourself

How It Works

When the worker script throws (or fails to load), your handler runs on the main thread.

Example 2 — addEventListener("error")

Same event; useful when several modules need to listen.

JavaScript
worker.addEventListener("error", (event) => {
  out.textContent = "error event fired";
  event.preventDefault();
});
Try It Yourself

How It Works

Prefer addEventListener when you do not want to overwrite an existing onerror.

📈 Details & Recovery

Read the message, contrast with message events, and clean up.

Example 3 — Read event.message

Browsers usually expose an error message string on the event.

JavaScript
worker.onerror = (event) => {
  console.log(event.message || "unknown worker error");
  event.preventDefault();
};
Try It Yourself

How It Works

Always guard with event.message || … in case a browser only gives a generic Event.

Example 4 — error vs message

A healthy worker replies on message; a throwing worker fires error.

JavaScript
worker.onmessage = (e) => console.log("ok:", e.data);
worker.onerror = (e) => {
  console.log("fail:", e.message || "error");
  e.preventDefault();
};
Try It Yourself

How It Works

Wire both handlers so success and failure each have a clear path.

Example 5 — Log, Terminate, and Restart

After a fatal worker error, stop it and create a fresh Worker.

JavaScript
worker.onerror = (event) => {
  event.preventDefault();
  worker.terminate();
  // create a new Worker(...) if the feature must continue
};
Try It Yourself

How It Works

A worker that already threw may be unusable; terminating avoids a zombie background thread.

🚀 Common Use Cases

  • Show a toast when a background job crashes.
  • Log worker failures to your monitoring service.
  • Stop waiting UI when a reply will never arrive.
  • Restart a worker pool member after a fatal script error.
  • Debug blob-worker demos when the script string has a typo.

🔧 How It Works

1

Worker fails

Script throw, load failure, or similar problem in the worker.

Fail
2

error event fires

The Worker object on the main thread receives the event.

Event
3

Your handler runs

onerror / addEventListener callbacks execute on the main thread.

Handle
4

Recover

Log, update UI, terminate, and optionally start a new Worker.

📝 Notes

  • MDN: Baseline Widely available (since July 2015) — no Deprecated / Experimental / Non-standard banner.
  • Available in Web Workers except Service Workers.
  • MDN event type is a generic Event; browsers often supply ErrorEvent details.
  • Attach handlers before starting heavy work.
  • Related learning: message, messageerror, terminate(), postMessage(), Worker().

Universal Browser Support

The Worker error event is marked Baseline Widely available on MDN (since July 2015). Logos use the shared browser-image-sprite.png sprite from this project. It is available in Web Workers except Service Workers.

Baseline · Widely available

Worker error event

Fires when an error occurs in the worker. Listen with onerror or addEventListener("error").

Universal Widely available
Google Chrome Full support · Desktop & Mobile
Full support
Mozilla Firefox Full support · Desktop & Mobile
Full support
Apple Safari Full support · macOS & iOS
Full support
Microsoft Edge Full support · Chromium
Full support
Opera Full support · Modern versions
Full support
Internet Explorer Supported with workers in IE10+ (prefer modern browsers)
Legacy
Worker error Excellent

Bottom line: Always attach an error handler when you depend on a dedicated worker—success uses message; failure uses error.

Conclusion

The Worker error event is how the main thread learns that a dedicated worker failed. Pair it with message for success, and recover with logging, UI updates, and terminate() when needed.

Continue with WorkerLocation.hash, message, terminate(), or the JavaScript hub.

💡 Best Practices

✅ Do

  • Attach onerror / listeners before posting work
  • Listen for both message and error
  • Log event.message when present
  • Terminate and recreate after fatal failures
  • Show clear UI when a background job fails

❌ Don’t

  • Assume try/catch around postMessage catches worker throws
  • Confuse app-level error messages with the error event
  • Leave the UI waiting after an error with no timeout
  • Overwrite onerror accidentally in shared helpers
  • Ignore load failures for missing worker scripts

Key Takeaways

Knowledge Unlocked

Five things to remember about Worker error

Main-thread signal that the worker failed.

5
Core concepts
📌02

onerror

or listener

Listen
💬03

≠ message

separate channel

Compare
🛑04

Recover

terminate / restart

Fix
🎯05

Baseline

since Jul 2015

Status

❓ Frequently Asked Questions

It fires on the Worker object when an error occurs in the worker script. Listen with worker.onerror or worker.addEventListener("error", handler).
No. MDN marks the Worker error event as Baseline Widely available (since July 2015). It is not Deprecated, Experimental, or Non-standard. It is available in Web Workers except Service Workers.
MDN documents it as a generic Event. In browsers you often receive an ErrorEvent with helpful fields such as message (and sometimes filename, lineno, colno).
message delivers successful postMessage data as event.data. error reports that the worker script failed. Do not confuse an application-level { type: "error" } message with the real error event.
Yes for production workers. Without a handler, worker failures can be easy to miss while the UI waits forever for a reply.
Some browsers let you call event.preventDefault() in the error handler to suppress the default error reporting UI/console behavior. Always still log and recover in your own code.
Did you know?

A try/catch around worker.postMessage(data) only catches problems sending the message on the main thread. Errors that happen later inside the worker arrive through this error event instead.

Next: WorkerLocation.hash

Learn how to read the fragment of a worker script URL.

hash property →

About the author

Mari Selvan M P
Mari Selvan M P 🔗

Developer, cloud engineer, and technical writer

  • Experience 12 years building web and cloud systems
  • Focus Full Stack Development, AWS, and Developer Education

I write practical tutorials so students and working developers can learn by doing—from databases and APIs to deployment on AWS.

5 people found this page helpful