How a hard-coded 404 destination becomes a real-time error in the LaunchDarkly Observability platform — captured from both the browser and the server.
Atlantis is a destination in Toggle Travel that always fails at checkout. When a user selects Atlantis and clicks Confirm, the server returns a 404 — Destination Not Found. No booking is created. The payment is never charged. The user hits a dead end.
This isn't a bug we need to fix — it's a deliberate demo signal. The question is: how quickly can your observability platform surface it?
A dark-red "404 — Destination Not Found" banner with the server's error message, the trace ID, and a "Browse other destinations" button.
bookingService.js throws a 404 immediately after the destination lookup — before any payment or database write. Winston logs the error, which routes to LD via the custom LDTransport.
How errors appear in the LD Observability Errors view
LaunchDarkly captures the Atlantis failure from both sides — server and browser — and correlates them with the same trace ID.
The LD Observability browser SDK automatically captures uncaught errors (unhandled promise rejections, window.onerror). But the Atlantis 404 is caught — the UI handles it to show the user a helpful banner.
If we didn't call LDObserve.recordError() manually, the SDK's auto-capture wouldn't fire and the error would be invisible to LD. Explicit recording is required any time you catch-and-display.
Not just Atlantis 404s — payment declines (402) and generic 5xx errors are also passed to recordError(). This means the LD Errors view reflects the full health of the booking flow, not just one failure mode.
This metadata is searchable and filterable on the LD Observability Errors view — you can filter to destination_id=dest-013 to see only Atlantis failures, or http_status=404 to see all not-found errors across the app.