Privacy Policy

Scope & roles

This policy covers performanceinsights.ai and the DumpTriage service. For DumpTriage, most personal data we handle comes from your uploaded crash dumps — memory snapshots that can incidentally contain personal data about your own end users, employees, or systems (usernames, file paths, tokens, or other fragments present in process memory at the time of the crash). In that relationship, you are the data controller and we are the data processor, acting only on your instructions under our Terms of Service and, where applicable, a data processing agreement. For your own account data (organization name, contact details, billing), and for anyone who visits our website, we are the controller.

What we collect

We currently don't use cookies, tracking pixels, or third-party analytics on this website. If that changes, this policy — and, where required, a consent mechanism — will be updated first.

Who we share it with

We don't sell personal data. We share it only with the subprocessors necessary to run the service. Our Subprocessors page lists each one, what it receives and where. In short:

• OVHcloud (France) hosts our API, database, database backups and encrypted dump storage, since 2026-10-15. Hetzner (Germany) hosted them before that; its server is switched off and kept as a fallback until we delete it, planned for 2026-10-22.
• Google Cloud (Netherlands) runs the Windows and Linux debuggers. The raw, decrypted dump, and any private symbol files you've uploaded, are copied to a worker VM there for the analysis.
• Google Cloud's Vertex AI receives redacted debugger transcripts for the AI-assisted analysis steps, never the raw dump file. It runs on Google's EU endpoint, so the request stays in the EU. How DumpTriage uses AI explains what each step sends. Until 2026-09-24 this step ran on Anthropic (United States), which received the same redacted transcripts.
• Anthropic (United States) provides Claude, the AI assistant our engineers use when they investigate a case or a problem with an analysis, and when we test AI models. It receives the debugger and forensic tool output, transcripts and report text they work with, which aren't always redacted first and can include user and folder names. It doesn't receive the raw dump file.
• Resend (United States) sends our emails, so it sees your contact address, organization name and the email text, including crash details in alerts to our staff.
• SMTP2GO (a New Zealand company; our account is hosted in the EU, where it sends, stores and processes our mail) is the standby for Resend. It sends the same emails, and sees the same things, only when Resend can't deliver one.
• Linear (United States) holds the case our engineers work on when a dump is escalated to a human: your organization name, dump identifiers and the crash details behind the escalation. Never dump files, transcripts or contact details.
• Slack (United States) is where our engineers get notified of those cases, so it sees the case title (your organization name and dump type) and crash details from the case. Never dump files, transcripts or contact details.
• Grafana Labs (United Kingdom) receives operational telemetry for monitoring and alerting: request paths without query strings, timings, internal identifiers and error messages. It never receives dumps, transcripts, reports or contact details.
• Microsoft's public symbol server, and for Linux dumps the public Linux debug-symbol servers of the major distributions, receive module and symbol identifiers (build IDs, package names and versions), not dump contents.

We may also disclose data if required by law, or to protect our rights, users, or the public.

Reuse of resolved cases

When one of our engineers resolves an escalated case, they can add a short summary of it to an internal knowledge base: the crash or exception code, the faulting module's name, a crash signature, a root-cause category and a note written by the engineer. It doesn't include the dump file or debugger transcripts. The code, module name and signature are values the debugger reported, and the note is written by our engineer. When a later dump from any customer has the same crash or exception code and faulting module (or, failing that, the same crash signature), up to five matching summaries from customers who allow sharing are included in the AI-assisted analysis of that dump. The module name, root-cause category and engineer's note are sent to Google Cloud's Vertex AI as part of that analysis. Summaries of your cases are only used this way if you turn sharing on: it is off by default, and you can change it at any time through the API (PUT /api/v1/customers/me/kb-sharing). Turning it off applies from the next analysis. Our engineers still decide which cases are worth summarising. Summaries of your cases are deleted when you close your account, or sooner if you ask.

Retention

The dump file and the full debugger transcripts produced from it are deleted 30 days after upload by default, or after the retention period configured for your account (at most 90 days). You can also delete a dump yourself at any time through the API. What remains of the dump's record is metadata only: its size, type, upload date, file hash and a keyed hash of the uploading machine's name. That metadata is deleted 6 years after the dump. Our internal audit log keeps the fact that your account uploaded it.

The analysis results go with the dump: the report's findings and, for escalated cases, the engineer's notes are deleted at the same time. What we keep is what our cost and speed measurements need: which analysis step ran, the model used, token counts, timings and a root-cause category. For an escalated case, that includes which of our automatic checks sent it to an engineer, in our own fixed wording (for example “heap corruption signature detected”), and the crash's standard error code (for example 0xD1 or SIGSEGV), but not module or program names, the stack or anything the AI model wrote. Case summaries in the knowledge base (see Reuse of resolved cases) are kept until you close your account or ask us to delete them, and only used for other customers' analyses if you allow it.

Escalated cases also exist outside our database: the case our engineers work on in Linear, and its notification in Slack (see Subprocessors). When the dump is deleted, for whichever of the reasons above, we remove the crash details from the Linear case and archive it, delete our own Slack messages about the upload, and replace the escalation's reason in our database with a placeholder; when the account is closed, we also remove your organization name from Linear. Notifications Linear itself posted to Slack when the case was opened can still show the case's original title and details; we delete those on request. Our server logs are capped in size and rotated, and the host's system log is kept for at most 30 days.

Private symbol files you upload are deleted 90 days after an analysis last used them (or after upload, if none did). You can delete one yourself through the API at any time, and closing your account deletes them all.

Closing your account. Before you close it, you can take a copy of everything: GET /api/v1/customers/me/export returns your account details, your dump list with download links and every report in one zip. Ask us if you'd like help getting a copy. When the account is closed, we delete every dump, transcript and symbol file it uploaded, and the analysis results and knowledge-base summaries of its cases, and we revoke its API keys. We also remove the organization name, contact and email from the account record. What stays is a record without your name or contact details: an internal id, the plan, settings, dates and usage counters. We keep it so our audit log and usage figures still add up, for 6 years after the account is closed, and then delete it. Invoices and payment records, if any, are kept for as long as tax and accounting law requires. Audit logs are retained longer, for security-investigation purposes, and contain command text only, never dump or transcript contents.

Backups. Our database is backed up once a day, and each backup is deleted after 14 days. So something deleted from the service, or removed when an account is closed, can remain in a backup for up to 14 days. Backups hold the database only, such as account records, report findings, escalation notes and the audit log. Dump files, transcripts and symbol files are never backed up. We use backups only to recover from a failure. If we ever restore one, we apply every deletion made since the backup again before the service comes back.

Security

Dumps are encrypted at rest. Each analysis runs on its own worker VM, created for the job and deleted afterwards. Workers only accept connections from our own servers and our engineers' addresses. We keep an audit log of the commands run against each dump and of staff actions on escalated cases, and we run a redaction pass on debugger output before any of it reaches a third-party AI model. We're still hardening parts of this during the pilot. If you need a non-disclosure agreement before one of our engineers reviews your dumps, ask us and we'll sign one. No system is perfectly secure; we'll notify affected customers without undue delay if we become aware of a breach affecting their data.

Health data (HIPAA)

DumpTriage isn't built for protected health information (PHI). We aren't a HIPAA business associate and we don't sign Business Associate Agreements: not every service we rely on offers one. If you're a HIPAA covered entity or business associate, or you look after systems that handle patient data, don't send us dumps of processes that hold PHI. A minidump holds much less memory than a full or kernel dump but can still contain fragments of it. Talk to us first at hello@performanceinsights.ai.

Your rights — EU/UK (GDPR)

If you're in the EU, EEA, or UK, you have the right to access, correct, delete, restrict, or port your personal data, and to object to certain processing. Our lawful bases are contract performance (running your account, delivering the service) and legitimate interest (security, fraud prevention, service improvement). DumpTriage stores dumps in the EU and runs the debugger in the EU. The AI analysis of redacted transcripts runs on Google's EU endpoint, so it stays in the EU too. Notification and case details go to Resend, Linear and Slack in the United States (see Subprocessors), so personal data in those details is transferred there. For these transfers we currently rely on each provider's own data protection terms. We haven't yet completed our own Standard Contractual Clauses and transfer assessments; we'll do that before we onboard a customer whose contract requires them, and update this section. To exercise a right, contact hello@performanceinsights.ai; we aim to respond within 30 days. If your data reached us through a dump uploaded by one of our customers, we'll generally direct you to that customer as the controller, unless they're unreachable.

Your rights — US state privacy laws

Depending on your state of residence (including California under the CCPA/CPRA, and similar laws in Virginia, Colorado, Connecticut, Utah, and other states), you may have the right to know what personal data we hold about you, to delete it, to correct it, to obtain a portable copy, and to opt out of the sale or "sharing" of personal data — we don't sell or share personal data as those terms are defined, so there's nothing to opt out of today. We don't discriminate against anyone for exercising a privacy right. To submit a request, email hello@performanceinsights.ai; we'll verify your identity before acting on it and respond within the timeline your state's law requires (typically 30–45 days).

Children's privacy

DumpTriage is a B2B service and our website isn't directed at children. We don't knowingly collect personal data from anyone under 16.

Changes to this policy

We'll update the "last updated" date above when this policy changes, and for material changes we'll notify active customers directly.

Contact

Questions, requests, or concerns about this policy: hello@performanceinsights.ai.