Building a Health Score From API Usage Instead of Login Counts

Seat-based products live or die on whether people open the app. Usage-based products live or die on whether the integration keeps running and keeps growing, and that has almost nothing to do with whether a human logs into a dashboard. A team that built a solid integration months ago might rarely open the web interface at all, because the product is running quietly in the background doing exactly what it's supposed to. Scoring that account as unhealthy because of low login activity would be exactly backwards. The health signal that actually matters is whether the underlying usage, the API calls, the data processed, the jobs run, is stable or growing against what the account is paying for.

Say an account is on a plan built around monthly API call volume. Track three inputs over a rolling window: the trend in daily call volume over the trailing thirty days compared with the thirty days before that, the share of days in the last two weeks where usage dropped to near zero, and how close current usage sits to the account's plan limit. An account trending upward in volume, with no zero-usage days, and comfortably under its limit scores healthy. An account trending flat with occasional zero-usage days is worth a closer look, since intermittent silence often precedes a real drop rather than following it. An account trending downward for two consecutive months, even if it hasn't hit zero, is the clearest early warning available, because a shrinking integration usually means someone on the customer's side has started building a workaround or has quietly deprioritized the project the integration supports.

Average volume alone smooths over a warning sign that matters: a single multi-day period of complete silence, even inside an otherwise healthy trend, deserves more attention than a gradual decline. A team with a broken API key, an expired credential, or a dependency that silently failed will show as zero usage, and if nobody's watching for that specifically, it can persist for weeks before the account either notices on their own or churns quietly, having concluded the integration wasn't worth fixing. Any health score for usage-based software should flag consecutive zero-usage days as its own signal, separate from the overall volume trend, since it often points to a technical problem rather than a business one, and technical problems are usually the easiest kind to fix quickly if caught early.

A few patterns show up repeatedly in usage-based health scoring that don't hold up:

• Scoring against a fixed volume threshold instead of a trend. An account that's always run at a modest, stable volume isn't unhealthy just because it's smaller than your biggest accounts.
• Ignoring seasonality specific to the account's own business. A retail integration that's quiet outside peak season isn't declining, it's following a pattern that should be modeled in, not flagged as risk every off season.
• Treating an account bumping against its plan limit as automatically healthy. High usage against a limit is genuinely a positive signal for expansion, but it can also mean the account is throttled or erroring out in ways that frustrate them long before anyone raises a pricing conversation.
• Building the score once and never revisiting it as usage patterns across your whole customer base shift with product changes or new feature adoption.

A health score that doesn't change anyone's behavior is just a number on a dashboard. Define what happens at each tier before building the score, not after: a flagged zero-usage account should trigger a same-week outreach from whoever owns technical support for that account, a declining-trend account should trigger a CSM conversation focused on what changed, and a healthy, growing account should feed directly into the expansion pipeline discussed elsewhere in this cluster. Building the scoring logic is the easy part. Making sure a specific tier reliably produces a specific action is where most usage-based health programs actually succeed or fail.

Review the response definitions themselves on the same cadence you review the scoring thresholds, not just once at launch. A tier that triggered the right action when the program started can quietly stop matching reality as your support team's capacity or your typical account size changes, and nobody notices until someone asks why a flagged account sat untouched for a month.