Rank errors by revenue impact, not raw count

Why this matters

Count-based triage is a trap. The loudest fingerprint in your error tracker is usually a cron loop hitting a stale row 5,000 times an hour — annoying, low-impact, fixable Tuesday.

Meanwhile the bug that three Pro accounts hit during checkout — twice each, total of 6 events — generated 80% of the revenue risk in that window. Sentry sorts it 80th on the list. You won’t see it until those three accounts churn.

The fix is to weight every error by the affected user’s plan value. Datadog won’t do this. Sentry won’t do this. The combination of error data + analytics data lives in one place in Agentry, so the agent can JOIN them in a single HogQL query and rank by dollars-at-risk instead of dumb count.

What you get

• Top 5 open cases ranked by estimated ARR-at-risk (users-affected × per-user ARR)
• For the #1 case: the specific accounts involved, with their plan tiers
• A suggestion for who at your company should call those customers today

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",
  since: "14d",
  include_affected_distinct_ids: true,
  limit: 25

{
  "cases": [
    { "id": "c_f72a", "message": "TypeError on user.plan", "users_affected": 14,
      "event_count": 89, "distinct_ids": ["[email protected]", "[email protected]", "..."] },
    { "id": "c_1cd9", "message": "fetch failed: invoice.pdf", "users_affected": 9,
      "event_count": 11, "distinct_ids": ["..."] },
    { "id": "c_2d8e", "message": "checkout 500: stripe webhook timeout", "users_affected": 3,
      "event_count": 6, "distinct_ids": ["[email protected]", "[email protected]", "..."] }
  ]
}

Endpoint: POST /v1/projects/:project_id/analytics/query
Exact shape: /v1/openapi.json?path=%2Fv1%2Fprojects%2F%7Bproject_id%7D%2Fanalytics%2Fquery&method=post
Custom HogQL goes in the OpenAPI-defined `query` field.
Concept fields:
  query: "SELECT distinct_id, argMax(properties.plan, timestamp) AS plan FROM events WHERE distinct_id IN ({ids}) GROUP BY distinct_id",
  params: { ids: ["[email protected]", "[email protected]", "[email protected]", "[email protected]", "..."] }

{
  "rows": [
    { "distinct_id": "[email protected]", "plan": "free" },
    { "distinct_id": "[email protected]", "plan": "starter" },
    { "distinct_id": "[email protected]", "plan": "enterprise" },
    { "distinct_id": "[email protected]", "plan": "scale" }
  ]
}

The output

Top 5 cases by ARR-at-risk (14d, open)

$63,000   c_2d8e   checkout 500: stripe webhook timeout
                   3 users  · 6 events
                   Affected: [email protected] (enterprise $30k),
                             [email protected] (scale $3k),
                             [email protected] (enterprise $30k)
                   ↗ Owner: @stripe-oncall — investigate webhook latency

 $4,200   c_f72a   TypeError on user.plan (free-tier path)
                   14 users · 89 events · mostly free tier
                   ↗ Low ARR, but fixable in 4 lines

 $2,700   c_1cd9   invoice.pdf fetch failed
                   9 users · 11 events · mixed plans
                   ↗ Probably CORS regression on invoice-service

   $600   c_a3e1   phone validation NANP-only
                   7 users · 14 events · all starter
                   ↗ Low priority unless we want international growth

   $300   c_4f01   pagination edge case
                   2 users · 3 events · starter
                   ↗ Easy fix, ship next sprint

Net ARR at risk: $70,800

Setting it up

The workflow joins two things: cases (your error data) and events (your analytics data, where plan lives). For the join to work, both must use the same distinct_id.

// Error reporting — distinct_id (or user.id) MUST match analytics
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 },  // ← same id as analytics
  }),
});

// Analytics — every event carries `plan` so we can JOIN later
await fetch(`https://api.agentry.sh/v1/analytics/`, {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.AGENTRY_SERVER_API_KEY}`,
    "Content-Type": "application/json",
    "User-Agent": "myapp/1.0",
  },
  body: JSON.stringify({
    event: "feature_used",
    distinct_id: currentUser.email,  // ← same id as errors
    properties: { plan: currentUser.plan, mrr: currentUser.mrr },
  }),
});

If you don’t track plan on every event, an alternative is to fire a one-shot plan_changed event whenever it changes — the HogQL argMax(properties.plan, timestamp) pattern picks up the latest value either way.

Variations

• “Same ranking, but only count enterprise customers (plan = ‘enterprise’).”
• “Show errors ranked by ARR-at-risk over the last 24 hours, not 14 days. Daily oncall summary.”
• “For the top case, draft a per-customer outreach email apologizing and offering credit.”
• “Run this on demand for the last business day and draft the top three for an authorized CS reviewer; do not expose affected emails automatically.”