Blog / Errors

How to set up global error handlers in a web app without double-reporting

The safest global error-handler setup has one automatic reporting path, one manual reporting helper, and one dedupe policy. Without that discipline, the same error often gets reported by the browser, the framework, and your catch block at the same time.

  • Pick one automatic handler path and make everything else cooperate with it.
  • Use a manual helper for high-value caught errors instead of re-sending every exception blindly.
  • Dedupe matters because alert fatigue starts with duplicated incidents, not just noisy bugs.

Definitions used in this guide

Breadcrumb trail

The sequence of user actions, route changes, and requests that happened before an error fired.

Error fingerprint

A normalized signature that groups repeated failures together even when line numbers or values vary slightly.

Impact summary

A plain-English explanation of who was affected, what they were doing, and why the error matters to the business.

What should be true before you start?

Before adding handlers, document what your runtime and framework already report automatically. React, Next.js, and browser-level handlers can overlap in surprising ways once an SDK also captures uncaught failures.

  • Check which global handlers the SDK already wires for errors and promise rejections.
  • List the framework-level boundaries or custom handlers already present in your app.
  • Decide where caught but important errors should call the manual helper instead of relying on global capture.

How should you implement this step by step?

The implementation pattern is simple: let one automatic path own uncaught failures, then build a small helper that dedupes manual capture for important caught errors. This keeps the signal complete without turning each exception into three incidents.

  • Keep the SDK's automatic uncaught error and promise rejection capture as the default path for unexpected failures.
  • Create one helper for manual reporting inside checkout, restore, export, or sync flows where caught errors still matter.
  • Use a dedupe strategy so the same Error object does not get reported by multiple boundaries or handlers.
  • Review grouped fingerprints after the first release to catch any remaining duplicate reporting patterns.
Manual helper with dedupe protection javascript
const seenErrors = new WeakSet()

function captureOnce(error) {
  if (error && typeof error === "object") {
    if (seenErrors.has(error)) return
    seenErrors.add(error)
  }

  Crossdeck.captureError(
    error instanceof Error ? error : new Error(String(error))
  )
}

Where do teams make mistakes?

Double-reporting usually starts as a harmless safety instinct, but it quickly turns into alert fatigue and misleading counts.

  • Adding browser handlers, framework handlers, and manual capture without a dedupe policy.
  • Re-wrapping every error into a new object and accidentally breaking grouping.
  • Using global handlers as a substitute for targeted manual reporting in revenue-critical flows.

How does Crossdeck operationalize the workflow?

Crossdeck works best when the reporting contract is explicit: unexpected failures are automatic, important recovered failures are manual, and both land on the same customer timeline with clean grouping.

That structure keeps alerts useful and preserves trust in the dashboard, because the team can believe one incident really means one incident.

Frequently asked questions

Do I need my own window.onerror handler if the SDK already captures globally?

Usually no. Add your own only when you have a clear reason and a dedupe strategy. Otherwise you will likely create duplicate incidents.

Why not manually capture every error everywhere?

Because it creates duplication, noise, and inconsistent grouping. Manual capture is strongest when it is used only for important, recovered failures.

How do I know I am double-reporting?

Look for the same fingerprint arriving multiple times per user action or for suspiciously inflated incident volume after adding a new framework boundary or handler.

Does Crossdeck work across iOS, Android, and web?

Yes. Crossdeck is designed around one customer timeline across Apple, Google Play, Stripe, and web or mobile product events, so the same entitlement and revenue model can travel across surfaces.

What should I do after reading this guide?

Use the CTA in this article to start free or go straight into read error capture docs so you can turn the concept into a verified implementation.

Take this into the product

Open the errors docs, confirm the SDK auto-capture path, and then add only the manual reporting helpers your premium flows actually need.