# Capture the handlers that never report

The three places errors escape entirely: unhandled rejections, uncaught exceptions, and the frontend error boundary.

Category: Error reporting and triage
Source: https://letsship.ai/use-cases/capture-unhandled-rejections
Published: 2026-08-25

## Goal

Register handlers for unhandled rejections, uncaught exceptions, and the frontend error boundary so nothing escapes unreported.

## Acceptance criteria

- Each of the three paths is registered and reports
- A seeded failure on each appears in the tracker
- The error boundary shows a usable interface rather than a blank page
- Handlers do not swallow the process exit behaviour they should preserve

## What lands as proof

Three seeded failures, one per path, each visible in the tracker with its stack.

## Prompt

Copy this to an agent to open the ticket:

```text
Create a Linear issue in my team and assign it to the SHIP agent.

Title: Capture unhandled rejections and uncaught exceptions

Description: Register handlers for unhandled rejections, uncaught exceptions, and the frontend error boundary so nothing escapes unreported.

Acceptance criteria:
- Each of the three paths is registered and reports
- A seeded failure on each appears in the tracker
- The error boundary shows a usable interface rather than a blank page
- Handlers do not swallow the process exit behaviour they should preserve

Before you create the issue, check which of the three handlers this repository already registers and list only the missing ones in the description.
```

## Questions

### What does the agent actually change?

The ticket is scoped to one outcome: register handlers for unhandled rejections, uncaught exceptions, and the frontend error boundary so nothing escapes unreported. Work that serves that outcome is in scope, and anything outside it is left for a separate ticket, so the pull request stays reviewable.

### How do I know the work is done?

The pull request carries the evidence, not only the diff. Here that means one seeded failure per handler, each visible in the tracker, so a reviewer can confirm the result without reproducing the work locally.

### How much oversight does this need?

None is required before the run starts. Every claim this ticket makes can be checked by machine, so the agent works straight through and a person reviews the finished pull request like any other.