Setup
1. Create a hook file
Create a file that registers your handler. ImportonError from @outputai/core/hooks.
2. Register the file in package.json
List your hook file(s) underoutput.hookFiles. Paths are relative to the package root. The worker loads these files at startup.
"hookFiles": ["./src/error_hooks.js", "./src/other_hooks.js"].
The three sources
Errors are emitted from three origins. The payload passed to your handler always includessource and error; workflow- and activity-scoped errors also include the names below.
| Source | When it fires | workflowName | activityName |
|---|---|---|---|
activity | A step or evaluator fails (after retries are exhausted). | ✅ Set | ✅ Set |
workflow | The workflow function itself throws (e.g. uncaught step error or logic error). | ✅ Set | ❌ Not set |
runtime | An error outside workflow/activity scope (e.g. in the worker/runtime). | ❌ Not set | ❌ Not set |
- For activity errors you get
source: 'activity',workflowName,activityName, anderror. - For workflow errors you get
source: 'workflow',workflowName, anderror(noactivityName). - For runtime errors you get
source: 'runtime'anderroronly.
source to branch in one handler, or ignore payload fields that are undefined for that source.
Handler safety: no throws
Your handler is wrapped in a try/catch. If the handler throws or rejects, the framework catches it, logs it (e.g.onError hook error with the error), and does not rethrow. Execution of the workflow and worker continues. You can focus on side effects (logging, metrics, alerts) without worrying about breaking the run.