error.page is an error-monitoring and user-experience service. You install our SDK on your website; it reports errors, pageviews and (if you turn it on) session recordings to us, and we show them to you in a dashboard. That means we handle two kinds of personal data: yours, as the account holder, and your users', as the people who visit your site. This policy covers both.
1. Data about you (the account holder)
- Account: name, email address, password hash, and the identifiers and avatar of any sign-in provider you connect (Google, Microsoft, Discord). Used to run your account and sign you in.
- Billing: if you subscribe, Stripe holds your payment method; we store your Stripe customer and subscription identifiers, plan, billing period and invoice history.
- Usage of the dashboard: we record how the dashboard itself is used (pages, clicks and, with text masked, a visual replay of your session) through the same SDK we offer you, to find and fix problems in our own product. Password fields are never captured; API keys and secrets shown on screen are blanked from recordings.
- Email: account emails (verification, incident alerts, usage warnings, billing notices) are sent to you as part of the service. You can switch incident alerts off on your profile. Product updates are only sent if you opt in.
- Security: IP addresses and user agents in server logs, sign-in events, and abuse signals (rate limits, banned addresses), kept for a limited time to protect the service.
2. Data about your users (visitors to your site)
For this data you are the controller and we are your processor: we process it on your instructions, as configured in your account, and only to provide the service to you. You are responsible for having a lawful basis and for telling your users, for example in your own privacy policy. What the SDK can send:
- Error reports: the error message and stack trace, the page URL and title, the request and response that failed (method, endpoint, status, and up to 2 KB of each body), browser and operating system, a short trail of recent clicks and page views, and any attachments your own code adds.
- Usage events: page views, clicks and custom events, with a pseudonymous visitor identifier the SDK stores in the visitor's browser, the referrer, a hashed IP address and a country derived from it. If your code calls
identify(), the user id, email and name you pass are stored and shown against their journeys. - Session recordings (if enabled on a paid plan): a replay of the page's DOM and interactions. All form inputs are masked unless you switch text capture on for a project; password fields are always masked. Elements you mark with
ep-maskorep-blockare masked or blanked. - Outreach: on your branded error page, a visitor may leave an email address to be told when an issue is fixed. The address is confirmed by email first (double opt-in) and is used only to send that one recovery notice for the incident they asked about.
We never sell this data, never use it to build profiles across customers, and never use it for advertising.
3. Retention
Error reports, usage data and recordings are kept for the retention period of your plan and then deleted automatically:
- Free: 30 days
- Pro: 90 days
- Business: 365 days
- Enterprise: as agreed in your contract
Deleting a project deletes its data immediately. Deleting your account deletes your projects, their data and your account record; billing records are kept for as long as tax law requires. Backups roll off within 30 days.
4. Who else sees it (subprocessors)
| Provider | Purpose | Data |
|---|---|---|
| Stripe | Payments and subscription billing | Billing name, email, payment method (held by Stripe), invoices |
| Mailgun | Transactional email delivery | Email addresses and the content of emails we send |
| Cloudflare | Custom-domain TLS certificates and edge | Custom hostnames and the traffic to branded pages served on them |
If you connect your own AI model key, your incident text is sent to that provider under your own agreement with them. If you configure your own sending domain (SMTP), recovery emails go through your mail server. If you connect GitHub or Jira, incident details you choose to file are sent there.
5. Cookies and local storage
The error.page website and dashboard use only essential cookies: a session cookie and a CSRF token so you stay signed in and forms are protected. There are no advertising or cross-site tracking cookies, so there is no cookie banner. On your site, the SDK stores a pseudonymous visitor identifier and session identifier in the visitor's browser storage so journeys can be followed across pages; you can disable usage tracking with usage: false.
6. Security
Data is encrypted in transit (TLS) and at rest where our hosting provides it. API keys and stored provider keys are encrypted in the database. Access to production is limited to people who operate the service. Optional per-project protections — origin allowlists, server-side secret keys and signed ingest tokens — are described in the security documentation.
7. Your rights
You can see and change your account details on your profile, export your data by asking us, and delete your account from your profile at any time. Depending on where you live you may also have rights to access, correct, restrict or object to processing, and to complain to a supervisory authority. Requests about data we hold as your processor (your users' data) should go through you; we'll help you meet them. Write to support@error.page.
8. Changes
If this policy changes materially we'll email account holders before the change takes effect. The date at the top is the version in force.