Two questions come up in every serious review: what happens if Gleap goes down, and what happens if data is lost. Here's where to look for both.
Current availability and incident updates are published at status.gleap.io. That's the first thing to check when the widget won't load or the dashboard is slow — before you start debugging your own deployment.
Subscribe to it. During an incident, the status page is updated well before anyone can answer a ticket about the incident.
Gleap's DPA commits to availability, resilience and recoverability as technical and organisational measures: protection against accidental or deliberate loss, systems designed to tolerate disruption, and procedures to restore data and access to it.
If your review needs specifics — backup frequency, retention, recovery objectives — request them from [email protected] rather than inferring them. Those answers are given per system and change as the infrastructure does.
For anything you'd be unable to reconstruct, keep your own export:
Contacts — exportable as CSV from your data export settings.
Tickets — exportable, filtered by type and status.
Help center content — readable through the API if you want a copy outside Gleap.
Most teams don't need this. It matters if you're contractually required to retain support records, or if the help center you've built represents months of work.
The messenger fails quietly: your app keeps working and the widget doesn't appear or doesn't send. It won't block your page or throw errors into your users' faces.
If your product depends on people being able to reach you during an outage, publish a support email address somewhere that doesn't rely on Gleap loading.
Personal data breaches are reported to affected customers immediately on becoming aware, with what happened, which data categories were involved, a contact point and the measures taken — so you can meet your own notification deadlines. Service incidents are additionally published on the status page.
