Where your incident data lives, and who can reach it.

Who controls the data

There are two ways to run this product, and they put the data in different places. Which one applies to you decides everything else on this page.

Managed service

We operate the workspace on our infrastructure. You remain the controller of your data; we act as your processor, on your instructions and for no other purpose.

Self-hosted

You operate the workspace on your own infrastructure. You are both controller and processor. We receive nothing and have no access.

On the managed service we do not sell, share, or reuse your data, and we do not use it to train any model. It is processed to run the service you asked for, and for nothing else.

What the software stores

Running the product creates records in your database in these categories:

Accounts

Email address, hashed password, role, optional two-factor secret, and registered passkey credentials.

Customers and projects

Names, error-tracker organisation and project identifiers, notification preferences, and an encrypted authentication token.

Issues and events

Issue metadata pulled from your error tracker and the event payloads attached to it, including whatever your application put in them.

Analyses

Model summary, root cause, risk level and score, suggested fixes, code context, and the raw provider response.

Operational records

Notification history, monitor results, team membership and invitations, and approval timestamps for applied changes.

Event payloads are the sensitive category. They contain whatever your application attached to an error — which may include user identifiers, request bodies, or headers. On the managed service this is the data we hold on your behalf, which is why what your application puts into an error payload matters more than any other control on this page.

Where the data goes

On the managed service, data reaches three places and no others:

• Our infrastructure, where the workspace, database, and queues run.
• The model provider we configure, which receives redacted issue and event context for analysis. Fields whose key matches the sensitive-key list are replaced with [REDACTED] before anything is sent.
• The channels you nominate — your email, Discord, or Telegram destinations, at the risk levels you choose.

Redaction matches by key name. A secret placed in free text, or under a field name nobody anticipated, is not detected — which is why we agree what may enter an error payload during onboarding rather than afterwards.

Self-hosted, the same paths exist but you configure all of them. Run a local model with notifications disabled and nothing leaves your network at all.

How stored data is protected

Integration tokens are encrypted with AES-256-CBC before storage and stripped from API responses. Access requires an authenticated session; two-factor codes and passkeys are available per user, and privileged routes are gated by role. The full control list, with the source file for each control, is on the security page.

Everything else — disk encryption, network boundaries, backup handling, and physical security — is a property of the infrastructure you deploy onto, not of this software.

Retention and deletion

The software does not expire records on its own. On the managed service the retention period is agreed with you and recorded in your data-processing agreement; when the service ends, your data is deleted from our systems and from our backups on the schedule that agreement sets.

Self-hosted, retention is entirely yours: nothing is removed until you remove it.

Deleting a customer or project removes its records through the application. Deleting an individual's data that appears inside an event payload means removing or redacting that event.

Questions about this document

Questions about the software’s behaviour belong in the public issue tracker. Questions about a specific running instance — including access requests and deletion requests from individuals — belong with the organisation that operates that instance.