Back
Draft, not legal advice. This is a standard-shaped starting point, not a document an attorney has reviewed. Automatic scrubbing (section 3) reduces, but doesn't eliminate, the risk that Event Data includes personal information — and there's still no data processing agreement, subprocessor list, or breach notification procedure. Both need attention before this is relied on with real customers.

Privacy Policy

Last updated: August 20, 2026

1. Overview

This policy covers two different kinds of data: information about you, as a person with a ForgeOps account, and the Event Data your applications submit through the ingestion API. They're handled differently, and it matters which one we're talking about — see section 3.

2. Account information we collect

  • Account details: name, email address, and password (stored hashed, never in plain text).
  • SSO: if your organization enables SAML or OpenID Connect, the subject identifier your identity provider asserts, plus whatever name/email it sends — nothing beyond what's needed to sign you in.
  • Usage and audit data: sign-in timestamps, IP addresses, and a record of sensitive actions taken in your organization (who invited whom, who resolved which issue, and so on) — kept as an audit trail for your own organization's owners and admins to review, not shared outside it.
  • A theme cookie, only for a signed-out visitor's dark/light preference; once signed in, that preference is stored on your account instead (see the in-app help guide for more).

3. Event Data — data your applications submit

When you configure an application to report into ForgeOps, whatever that application sends — exception messages, backtraces, and any request or user context you choose to attach — is stored so it can be shown back to you. We don't control what's in that payload. If your application's exceptions or context data include personal information about your own users (an email address in an error message, a user ID in a backtrace, and so on), that comes through to us as-is.

Before anything is stored, likely-sensitive content is automatically redacted: email addresses, formatted SSNs/credit cards, known API key and token formats, and any field whose name suggests it holds a secret (password, api_key, and similar) — you can add your own field names for this on a per-project basis in that project's settings. This is a safety net, not a guarantee — pattern-based scrubbing of free text can't catch everything, and you're still responsible for what your applications send. Configure your error reporting to avoid including sensitive data in the first place where your own compliance obligations require it. Per-project retention settings control how long Event Data is kept before automatic deletion; deleting a project or organization removes it immediately and permanently.

4. How we use this information

To operate the Service: authenticating you, displaying your organizations' issues back to you, sending the alerts you've configured, and maintaining the audit log. We don't sell personal information, and we don't use Event Data for anything beyond providing the Service back to the organization that submitted it.

5. Sharing and third parties

Notification channels (Slack, email, or a generic webhook) are configured by your organization's own admins, and issue data is sent to whatever destination they've set up when a rule fires — that's a disclosure your organization controls, not one we make on your behalf. Otherwise, we don't share account or Event Data with third parties except as required by law. [Placeholder — a real subprocessor list (hosting, email delivery, etc.) belongs here once those vendors are finalized.]

6. Security

Passwords are hashed, never stored in plain text. SSO client secrets are encrypted at the column level. Production traffic is served over HTTPS. [Placeholder — this section shouldn't claim a certification (SOC 2, ISO 27001, etc.) the Service doesn't actually hold; add real ones here only once they exist.]

7. Your rights

You can review and remove your own account and organization data directly in the Service at any time — including permanent deletion of a project or organization. For anything that requires our involvement (e.g. a formal data subject access or deletion request under GDPR/CCPA), contact us using the details below.

8. Children's privacy

The Service isn't directed at, and isn't knowingly used by, children under 13.

9. Changes to this policy

We'll update the date above when this policy changes, and make a reasonable effort to notify account owners directly of material changes.

10. Contact

Questions about this policy, or a data subject request: [placeholder contact address].