Exception tracking

Exception tracking is the core of Quiet Guard: every error your app throws is captured, grouped and tracked over its lifecycle. You reach it by opening a project in the /app panel and going to its Issues tab.

How ingestion works

Your client POSTs an exception payload to /api/v1/ingest authenticated with the project key. The server validates it, applies your team's monthly quota, then hands it to the ingestor. A successful call returns 202 Accepted with the issue's public identifier. The full payload shape is documented in the Ingestion API reference.

Each accepted exception becomes an occurrence. Occurrences are grouped into Issues.

Fingerprint grouping into Issues

Rather than store thousands of identical errors as separate rows, Quiet Guard groups them. A deterministic fingerprint is computed from:

  • the project,
  • the exception class,
  • the file (path-normalised), and
  • the line.

All occurrences sharing a fingerprint roll up into a single Issue, with an occurrence counter that concurrent reports cannot lose, the date it was first seen and the date it was last seen.

Why path normalisation? Deploy tooling often serves the app from a timestamped directory (e.g. /releases/20260628/...). The fingerprinter strips that noise, keeping the path from the first /app/, /src/ or /vendor/ marker, so the same error groups together across deploys instead of fragmenting on every release.

Occurrences

Open an Issue to see its detail page: the grouped class and message, where it happens, how many times it has been seen, and the list of individual occurrences. Each occurrence carries its own stack trace, request context, environment and release, captured at the moment it happened.

Resolve, ignore, reopen

Every Issue has a status:

  • Open: active, needs attention (the default for a new issue).
  • Resolved: you have fixed it; it drops out of the active list.
  • Ignored: noise you do not want to act on; kept but muted.

You move between states with the actions on the issue list and the issue detail page. Filters let you focus on, say, only open issues.

Regression reopen

If an Issue is Resolved and the same error happens again, Quiet Guard treats it as a regression: the issue is automatically flipped back to Open on the next occurrence, and an issue.reopened alert is fired to any subscribed notification channels. You do not have to babysit resolved issues, if they come back, you will hear about it.

Release → commit correlation

If an occurrence carries a release (a commit SHA, sent in the payload context.release), and the project is connected to GitHub, Quiet Guard maps that release to the exact synced commit. From the issue you can jump to the commit that shipped the broken code, closing the loop from error seen in production to the change that caused it.

Note: release correlation only resolves when the release value is a hexadecimal commit SHA and the matching commit has been synced from GitHub.

Triage workflow

The project's Issues tab opens as a triage view: the status filter defaults to Open and every filter sits above the table. The 24h column counts each issue's occurrences over the last day, spot the burst happening right now, not last week's noisy issue. Select several issues to resolve or ignore them in one action.

Assigning issues

Assign an issue to a team member from the list or from the issue page. The Assigned to me filter turns the list into a personal worklist, perfect for agencies splitting projects across developers.

Logs around an event

When your plan includes application logs, the issue page shows the logs recorded on the same project and environment within ±5 minutes of the latest occurrence, the "why" often hides there. Each line links to the full log entry.

Press ⌘K / Ctrl+K anywhere in the panel to find issues by exception class, message or file, and projects by name. With encrypted storage, sealed messages are not searchable (by design): search relies on the clear metadata.

What's next

← Previous Getting started
Next → Application logs

You are reading the Quiet Guard v1.0 documentation.