If PoolStamp's support team ever asks for a "Sentry event id" during a bug report, this is the walkthrough. Most users never need this — it's for the edge cases where something crashed and we need to see the exact call site.
What Sentry is
Sentry is the crash-reporting service PoolStamp uses to capture unexpected errors in the mobile app and web admin. When something crashes, the app sends a scrubbed report (stack trace + device model + app version + your operator id) to Sentry. No customer data, no photos, no chemistry readings.
Finding the event id
- Mobile: after a crash, the app shows a "Something went wrong" screen with an Event id in small text at the bottom. Screenshot it and paste it in your support email.
- Web admin: any 500-error page includes an Event id in the details drawer. Right-click → Copy.
What to include in the support email
- The event id.
- The action you were doing when it crashed ("adding a new customer with a comma in the name", etc.).
- Whether it repeats. If you refresh and try the same action, does it crash again? A repeatable crash gets top priority.
- Screenshot if the UI showed anything odd before the crash.
Turning off telemetry
If you'd rather not send crash reports, turn it off in Settings → Privacy → Send crash reports. You lose faster debugging, but no crash data leaves your device. The app itself still works identically.
What we do with the report
Support forwards the event id to engineering. Engineering opens the event in Sentry, sees the stack trace, ships a fix, and closes the loop with you. Turnaround for a repeatable crash is typically same-day.
Data retention
Sentry events are stored for 90 days, then deleted. Personally identifying fields (name, email) are hashed before they leave the device. Custom scrubbing rules are documented at https://poolstamp.com/privacy#telemetry.