Customer impact, on every alert

With a roster in place, every alert, postmortem, and root-cause analysis carries who was affected— “3 Enterprise · 12 Pro · 47 Free” — computed by scanning the incident window for your customer-id field and joining to the roster. On-call decides wake up vs. wait from the notification itself, and your VP of CS reads the same alert as your engineers.

Time to wire: ~10 min · Needs: a customer-id field in your logs + a roster

Prerequisites — read these before pasting anything

Your logs carry a customer identifier — customer_id, tenant_id, account_id, or similar — on roughly 30% or more of lines. Below that, attribution has too little to join on and counts read as undercounts.
Epok auto-detects which field is your customer id once it has seen ~24h of logs. Sooner than that, or if it picks the wrong field, set it manually under Settings → Detection → Field Mappings — the same surface covered in detection tuning.

1. Paste the roster

Settings → Customers takes a CSV paste straight from your CRM export. Only customer_id is required — it must match the values that appear in your logs. name and tier are what make alerts readable; the rest is optional.

roster.csv — customer_id is the join key

csv

customer_id,name,tier,contract_value_band,account_owner
acme,Acme Corp,Enterprise,$100k+,sarah
stark,Stark Industries,Enterprise,$100k+,sarah
globex,Globex,Pro,$10-50k,raj
initech,Initech,Free,,

Limits worth knowing up front: up to 5,000 rows per import, and imports are atomic— if any row fails validation, the whole import is rejected rather than half-applied. A BOM from an Excel export is handled; you don't need to clean it.

Or wire it by API

Same contract, scriptable — sync your roster nightly from the CRM if it churns. source_kind accepts csv or json (a list of row objects with the same field names).

Bulk import

bash

curl -X PUT 'https://app.getepok.dev/api/v1/tenants/YOUR_TENANT_ID/customers/bulk' \
  -H 'Authorization: Bearer YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{
    "source_kind": "csv",
    "content": "customer_id,name,tier\nacme,Acme Corp,Enterprise\nglobex,Globex,Pro"
  }'

Verify it's working

Wait for the next alert (or open any recent one).
The alert detail shows a Customers panel with the per-tier stack and the top affected accounts by error count. The same rollup appears in Deep RCA and postmortems.
Attribution recomputes as an incident evolves, debounced to ~15 minutes per alert so it never adds query load during a storm.

Counts look wrong

“N customer ids appeared in logs but weren't in your roster” — the join is working; the roster is incomplete. The alert links you straight to add them.
No Customers panel at all — no customer-id field detected yet. Check Field Mappings (prerequisite 2), or you have less than 24h of logs and no manual override.
Counts feel low — check what share of your log lines actually carry the id field. Attribution can only count what the logs name.

What you don't need

No SDK, no code change, no new field to start emitting — attribution joins on an id your logs already carry. And no per-seat CS tooling: the point is that the person deciding whether to escalate reads the impact in the same alert the pager delivered.

Alerting — route the tier-stacked alerts to Slack or PagerDuty.
Detection tuning — field mappings, including the customer-id override.