Developer Experience Metrics That a Green Dashboard Hides

Your status page can be green while every new evaluator dies on device-code login. APM sees the requests that reached you. It does not see the CLI that exited on their laptop before a session existed.

Put three numbers next to traffic: median time to first successful call, the count of distinct hashed developers per error code, and the share of those probes that became a reviewed GitHub draft. Traffic without those is a vanity chart.

One script in a retry loop can look like an outage. Unique identities, hashed, tell you whether fifty developers hit the wall or one cron job did. You do not need their email to know the quickstart is broken.

Break the counts by version and by command. A spike on a new SDK version is a release problem. A spike on auth login across versions is a standing trap.

More tickets can mean you made reporting easier, which is good, or that the product got worse. Pair the ticket count with the probe count. If probes rise and drafts stay at zero, nobody is reading the inbox. If probes fall after a doc change, the fix worked.

The developers who never appear in either number are the ones who left before instrumentation. Start the probe in the first command of the quickstart, not after they are a paying workspace.

Once a week, read the intent lines for the top code. The metric says something failed. The sentence says whether they were lost, blocked, or hitting a real defect. That reading is the DX review.

Ship one quickstart change from that review. Metrics that do not change the sample are a report, not a practice.