Server-Side Mobile App Crash Event Reporting

Use Hardal to forward crash and error events that reach your backend. This gives product and data teams a first-party event stream they can join with app version, session, and release data. It complements a native crash-reporting SDK. It cannot recover a crash that the device never persisted or sent.

Recommended flow

1. Let the mobile SDK persist the crash report locally when required.
2. Upload the report after restart or from the app process when the platform allows it.
3. Validate and redact the payload in your backend.
4. Send a normalized event to Hardal with an idempotency key.
5. Reconcile accepted events with the source crash system.

Example event

{
  "type": "event",
  "payload": {
    "website": "your-signal-id",
    "name": "app_crash",
    "platform": "app",
    "data": {
      "event_id": "crash_01J...",
      "crash_type": "fatal",
      "error_class": "NullPointerException",
      "app_version": "2.1.3",
      "os_version": "iOS 18.6",
      "release_channel": "production"
    }
  }
}

Avoid placing raw personal data, access tokens, form values, or full request bodies in error messages and stack traces. Redact them before the event leaves your backend.

Metrics to monitor

• reports created by the source SDK versus events accepted by the backend
• backend events accepted versus events received by Hardal
• duplicate rate by event_id
• delivery latency at the median and tail
• crash-free sessions by app version
• fatal and non-fatal error rates after each release

Set a target for each metric from your baseline. A percentage in a generic guide cannot tell you how iOS background limits, Android process death, offline devices, or your own retry queue behave.

See Hardal for mobile measurement for app instrumentation and web and mobile measurement for a shared event model across surfaces.