Find the bugs 5 people hit but no one reported

Why this matters

For every customer who reports a bug, 8 silently leave. That’s the most well-replicated number in SaaS support research.

Your error tracker probably has dozens of unique fingerprints hitting multiple users — sorted by frequency, you see the loud ones (5,000 events from one cron loop, mostly noise). Sorted by users-affected, you see the silent killers: 14 different paying customers hit the same checkout error and not one of them filed a ticket.

Fixing the top 5 silent bugs every Friday afternoon is the highest-ROI hour of engineering you can spend. Agentry surfaces them with one prompt.

What you get

• A ranked list of open cases by distinct users affected
• Filtered to cases you’ve never looked at (no agent_summary yet)
• For each: the message, file/line, when it started, last seen

Walk through it

Endpoint: GET /v1/projects/:project_id/cases
Exact shape: /v1/openapi.json?path=%2Fv1%2Fprojects%2F%7Bproject_id%7D%2Fcases&method=get
Use query parameters, not a JSON body.
Query/filter concept:
  status: "open",
  min_users_affected: 3,
  triaged: false,
  since: "7d"

{
  "cases": [
    { "id": "c_f72a", "fingerprint": "f_72a", "error_type": "TypeError",
      "message": "Cannot read properties of undefined (reading 'plan')",
      "users_affected": 14, "event_count": 89, "first_seen_at": 1746748800,
      "last_seen_at": 1747353200, "agent_summary": null },
    { "id": "c_1cd9", "fingerprint": "f_1cd9", "error_type": "NetworkError",
      "message": "fetch failed: invoice.pdf download",
      "users_affected": 9, "event_count": 11, "first_seen_at": 1746834200,
      "last_seen_at": 1747291000, "agent_summary": null },
    { "id": "c_a3e1", "fingerprint": "f_a3e1", "error_type": "ValidationError",
      "message": "phone_number format invalid (NANP expected)",
      "users_affected": 7, "event_count": 14, "first_seen_at": 1746920000,
      "last_seen_at": 1747350800, "agent_summary": null }
  ]
}

The output

🐛 3 silent bugs (3+ users, last 7d, untriaged)

  14 users · TypeError: Cannot read properties of undefined (reading 'plan')
            UserMenu.tsx — null-check missing on free-tier path
            ↗ likely fix: 4-line guard

   9 users · NetworkError: fetch failed: invoice.pdf download
            BillingPage.tsx — CORS on new invoice service?
            ↗ verify CORS headers in invoice-service deploy

   7 users · ValidationError: phone_number format invalid (NANP expected)
            SignupForm.tsx — international users blocked
            ↗ switch validator to libphonenumber or relax the check

Cumulative customers silently impacted: 30

Setting it up

This workflow works the moment errors start flowing — no extra instrumentation needed beyond what /install.md already wires up.

To make it more useful, also send user.id or user.email with every error event so “users affected” is accurate. Agentry has no SDK — just raw fetch:

async function logError(err: Error, currentUser?: { email: string }) {
  await fetch(`https://api.agentry.sh/v1/logs/`, {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${process.env.AGENTRY_SERVER_API_KEY}`,
      "Content-Type": "application/json",
      "User-Agent": "myapp/1.0",  // REQUIRED — Cloudflare 403s default UAs
    },
    body: JSON.stringify({
      message: err.message,
      stack: err.stack,
      user: { id: currentUser?.email ?? null },  // ← THIS LINE
      environment: process.env.NODE_ENV,
    }),
  });
}

Without that, “users affected” falls back to distinct IPs, which is OK for browser apps but undercount-prone for server errors.

Variations

• “Same query but for production only — staging errors don’t count.”
• “Show me silent bugs that have been around for 30+ days. We’ve collectively decided to ignore these — should we?”
• “For each silent bug, tell me roughly how much revenue is impacted (cross-reference users-affected with their plan).”
• “After I ship a fix for case c_f72a, watch for it to drop to zero and post a confirmation in #eng.”