customers marked inactive while still calling the API daily: last_seen only updated on web login

TL;DR

Your customers did not go quiet, your definition of seen did. When last_seen is written only by the web login path, API driven customers who use the product heavily every day age into inactive and then into churn risk, while their API keys hammer your servers. Add activity recording to the API and integration paths, merge the signals into one last activity view, and clear the false inactivity from health scoring before a CSM calls a happy power user to ask why they left.

customers marked inactive while still calling the API daily: last_seen only updated on web login

Use this when

• Accounts marked inactive or at risk show heavy recent API traffic in server logs
• The affected accounts are API first or integration driven customers
• Web based accounts activity records look accurate

Not for this skill when

• The accounts API traffic is automated health checks or a single integration ping, not real product use
• Activity is missing everywhere including server logs, meaning the accounts really did stop

Steps

1. Prove the activity from server truth. For three flagged accounts, pull API request logs for the last fourteen days grouped by API key and endpoint, and confirm the traffic is meaningful product work, reads and writes across real endpoints, rather than a monitoring ping or a retrying dead integration repeating one failing call. Verify: the sampled accounts real API activity is confirmed from server logs
2. Find every place lastseen is written in the codebase and list which surfaces write it, web session, mobile, API authentication, API requests, integrations, and background jobs the customer configured. The gap list is the fix list, and usually the API paths authenticate successfully thousands of times without anyone recording that the customer was here. Verify: every writer of lastseen is listed and the missing surfaces are named
3. Decide the activity model properly. Define which events count as customer activity per surface, successful API calls with sensible exclusions for pure health endpoints, integration syncs initiated by the customer, and product actions, and store last activity per surface plus a combined value, rather than one overloaded timestamp every team interprets differently. Verify: the per surface activity definitions are written and agreed with CS and product
4. Implement recording on the missing paths with low cost writes. Update activity asynchronously or in batched form so the API hot path does not gain a database write per request, backfill per surface activity from retained API logs where they exist, and keep the raw surface values visible so CSMs can see how a customer is active, not only that they are. Verify: activity from a live API key appears in the per surface record in a test within the expected delay
5. Recompute inactivity and health for the affected population, produce the list of accounts whose risk status changes purely from this fix, and have their CSMs review it before any outreach based on the old status goes further, because some customers may already have received misguided save attempts that need a quiet correction. Verify: the status change list is reviewed and pending misguided outreach is stopped
6. Add a coverage monitor that compares the count of accounts with API traffic against accounts whose API activity updated, alerting when they diverge, and repeat the writer audit whenever a new surface launches, since every new client, integration, or agent interface restarts this bug unless activity is on its launch checklist. Verify: the coverage monitor runs and the launch checklist gains the activity item

Why it happens

Activity fields are usually built when a product has one surface, and they record the event that surface naturally has, the web login. As the product grows APIs and integrations, customers shift their real work to surfaces that never write the field, but downstream health logic keeps reading it as the truth about engagement. The field did not break, the products shape changed around it, and the customers most invested in the API became the ones who looked most gone.

Compatibility: Product activity tracking across web, API, and integrations, server request logs, and health scoring inputs, in current application stacks.

Variants and edge cases

customer inactive but API active last_seen

['The direct phrasing. Server logs are the ground truth that settles it in minutes, start there.']

last_seen only updates on web login fix

['The implementation variant. Per surface activity with a combined rollup is the durable model, a single shared timestamp will be redefined by every surface team.']

API customers flagged churn risk falsely

['The CS variant. Quantify affected accounts and review any save outreach already sent, false risk flags waste the customers patience as well as CSM time.']

Edge cases to work through before you close the incident:

• Not every API call is engagement. A failing integration retrying for weeks is a support issue wearing an activity costume, so exclude pure error traffic from activity and route it to support signals instead.
• Batch and asynchronous activity writes can lag. Publish the expected delay so CSMs do not re-investigate accounts whose activity is minutes behind.
• Machine users and service accounts need an owner mapping to a customer account, or their activity floats unattached and the coverage monitor will keep flagging it.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstJzyY1Flel_C-fJm5tkieQ