ErrorGuard User Guide

ErrorGuard is error tracking for your applications: exceptions group into issues with occurrence counts, first/last-seen times, and a resolve/regress lifecycle — so a thousand identical stack traces read as one problem, not a thousand log lines. Ingest is Sentry-compatible: point any existing Sentry SDK at your ErrorGuard DSN and errors flow in. There is no MicroGemLabs client library to install.

1. Create a project at /errors/projects — one per app or service. Each project gets a DSN (https://<key>@<host>/<project-id>).

2. Point your SDK at it. Replace the dsn in your existing Sentry.init(...) / sentry_sdk.init(...) call. Set tracesSampleRate: 0 — ErrorGuard ingests errors, not performance transactions (transaction envelopes are accepted and discarded, so leaving tracing on wastes bandwidth but breaks nothing).

3. Errors group into issues. Events sharing a fingerprint (exception type + top in-app stack frames, or your SDK-supplied fingerprint) collapse into one issue that counts occurrences.

4. Work the issue list at /errors/issues: resolve what you've fixed, ignore what you don't care about. A resolved issue that happens again automatically reopens as regressed — that's your "the fix didn't hold" signal.

Two events fan out to your on-call escalation policy and the /incidents feed (both toggleable per project):

• New issue — an error fingerprint seen for the first time, at error or fatal level.
• Regression — a resolved issue recurring.

Recurrences of an already-open issue never alert — the counters are the signal. This is what keeps ErrorGuard quiet during an error storm: one issue counting up, not a thousand alerts.

MicroGemAgent sees your open issues in every scan and chat session, alongside monitors, cron checks, and logs — so "why is checkout failing?" can correlate an error spike with the deploy that caused it.

Anything that speaks the Sentry protocol: @sentry/browser, @sentry/node, @sentry/nextjs, sentry-sdk (Python), sentry-ruby, sentry-go, sentry-php, and the rest. Both the modern envelope endpoint and the legacy /store/ endpoint are implemented.

Quick test without an SDK:

curl -X POST "https://<host>/api/<project-id>/store/" \
  -H "X-Sentry-Auth: Sentry sentry_key=<your-key>" \
  -H "Content-Type: application/json" \
  -d '{"message":"ErrorGuard test event","level":"error"}'

• Free: 1 project, 7-day event retention.
• Pro ($5/mo): 20 projects, 1-year event retention.
• Ingest is rate-limited per DSN key (240 events/min — Sentry SDKs back off automatically on 429).
• Events are pruned by the retention window; issues persist with their counters and timestamps, so history survives pruning.
• Event payloads are trimmed on ingest: the rendered stack trace (top 12 frames), tags, user, request URL, and runtime info are kept; breadcrumbs and attachments are dropped.

• One project per deployable unit (api, worker, frontend), not per environment — use the SDK's environment option to split staging/production inside a project.
• Set release in your SDK init: issues track which releases they've been seen in, which answers "did the new deploy fix it?" at a glance.
• Custom grouping: if the default fingerprint groups too aggressively (or not enough), set fingerprint on the SDK's event scope — ErrorGuard honors it.
• Pause a project during load tests — ingest returns 200 and discards, so your app never queues retries.