Error events

Error events surface user-facing failures so the team can fix them before they degrade trust. The taxonomy is intentionally minimal — 5 event names cover every type of error the user can actually perceive. Backend-only errors are tracked separately in server logs.

The five error events

app_route_not_found

User hit a 404. Properties: `attempted_path`, `referrer_class`, `locale`. Drives broken-link detection + missing-content prioritization.

app_route_error

Server-side render error (Angular SSR failure). Properties: `error_message`, `route`, `locale`. Should be 0 in healthy deployments.

form_validation_error

Client-side validation failed on form submit. Properties: `form_id`, `field_name`, `error_code` (required / format / range / consent_missing).

api_error

A background API call failed (data fetch, search, autosuggest). Properties: `endpoint`, `status_code`, `error_class` (network / timeout / 4xx / 5xx).

image_load_error

An `<img>` element failed to load. Properties: `image_url`, `surface`, `entity_id?`. Triggers the SVG editorial fallback (e.g. on Founder File covers).

Sampling rules

• All 404s are tracked (volume is low enough to be useful in raw form).
• api_error events are tracked at 100% during the first 60 days of any new API integration, then dropped to 10% sampling once baseline error rates are known.
• image_load_error events are sampled at 10% — they are usually CDN issues that bulk-fail in waves, so sampling preserves signal without flooding.
• form_validation_error events are tracked 100% always — they are the most actionable error signal.