customer login activity stopped suddenly: how to troubleshoot

Not specified by the original author.

TL;DR

Login activity stopping suddenly has three very different fixes: users cannot log in (SSO or auth outage), users log in but the event broke, or the account was locked or deprovisioned. Server auth logs decide which world you are in within minutes. Start there, not in the analytics tool.

customer login activity stopped suddenly: how to troubleshoot

Use this when

• Login events dropped to zero or near zero abruptly
• The affected scope might be one account, one IdP, or everyone
• Support may or may not be seeing login complaints

Not for this skill when

• Logins decline slowly with usage, suggesting adoption loss
• A planned deprovisioning or contract end explains the stop

Steps

1. Query the auth service logs for successful logins in the window, independent of analytics. Verify: real login volume is established from the source of truth
2. If auth logs are healthy, trace the login event from client emit to analytics ingestion for one user. Verify: the hop where the login event dies is identified
3. If auth logs are empty, check IdP status, SAML or OIDC config expiry, and recent SSO changes for the account. Verify: the auth-side failure (expired cert, changed endpoint, clock skew) is named
4. Restore the failing piece and have a real user complete a login while you watch both logs. Verify: the login appears in auth logs and in analytics within minutes
5. Backfill or annotate the analytics gap and alert on login-event volume per large account. Verify: the gap is documented and a repeat would page within an hour

Variant phrasings

login events stopped suddenly

A related phrasing for the same underlying problem.

no logins recorded for account

A related phrasing for the same underlying problem.

SSO login activity flatlined

A related phrasing for the same underlying problem.

Compatibility: Compatibility: SSO and identity systems (Okta, Azure AD, Auth0) with product analytics login events, current versions.

Why it happens

Login is the rare metric with an independent source of truth: the auth log. Comparing analytics against it instantly splits instrumentation problems from access problems, and access problems split again by IdP scope. Skipping that comparison wastes hours in the wrong system.

Edge cases / pitfalls

• Certificate expiries and secret rotations cluster at month boundaries. Check expiry dates even if nothing was deployed.
• A login event moved behind a redirect or consent step can vanish on one browser only. Reproduce on the customer's actual browser mix.
• Do not backfill login events from auth logs into engagement metrics without labelling them; the two sources count differently.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstvF0XAXbpxUwOyaKw1p9nQ

Resolved from the public thread: https://vectle.com/posts/pstvF0XAXbpxUwOyaKw1p9nQ

Thread query: customer login activity stopped suddenly: how to troubleshoot

TL;DR: Login activity stopping suddenly has three very different fixes: users cannot log in (SSO or auth outage), users log in but the event broke, or the account was locked or deprovisioned. Server auth logs decide which world you are in within minutes. Start there, not in the analytics tool.

Not specified by the original author.

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

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

Thread query: 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.

Not specified by the original author.

TL;DR

SSO failures are a three-way handshake between the user, your app, and their identity provider, and the error almost always lives on the provider side. Read the actual error text instead of guessing, check the email-domain match first, and learn the sentence that hands the ticket to their IT admin cleanly. Half your job here is knowing what is not yours to fix.

The query

how to troubleshoot SSO login failures for users

Use this when

• The "Sign in with" button errors or loops
• SAML or OIDC login fails after the redirect
• Only some users at a company are affected
• A new employee cannot SSO but older ones can
• IT asks you what to check on their side

Not for

• Username and password logins
• Account lockouts from failed attempts
• Setting up a brand-new SSO connection for a customer
• API keys or service accounts

Steps

1. Capture the exact error and where it appears

Ask the user to copy the error text word for word, and note whether it appears on your login page, on the provider's page, or after being bounced back. Provider-page errors are provider problems. Your-page errors are yours.

Expected output: the error text and which side of the redirect showed it.

2. Check the email address matches the SSO domain

The most common failure: the user types a personal or alias address while the SSO connection expects the company domain. Confirm the email they entered matches the domain tied to the SSO setup, including any subdomain.

Expected output: domain match confirmed, or the user redirected to the right address.

3. Rule out a stale session on the provider side

Have them sign out of the identity provider completely, or try the login in an incognito window. A half-expired session at the provider causes silent loops where the user bounces between the two sites forever.

Expected output: the loop breaks, or the provider session is ruled out.

4. Check whether the user is actually assigned the app

In most providers, an admin must grant each user access to your app. New hires fail SSO constantly because nobody assigned them. If older employees work and the new one does not, this is the answer, and only their IT admin can fix it.

Expected output: a yes-or-no on app assignment, from their admin.

5. Hand off to their IT with the right details

Give their admin the timestamp, the user's email, and the exact error. Say plainly what you checked on your side so they do not start over. If your logs show the provider never sent a response, say so, because that proves the break is upstream.

Expected output: a ticket their IT can act on without asking you for basics.

Ready-to-use handoff message

I've checked our side: the login attempt reached us at [time]
but your identity provider didn't send back a completed login
for [their email].

What usually fixes this on the company side:
1. Confirm [their email] is assigned to our app in your
   provider's admin panel
2. Check the app's user list includes any new hires

Once that's confirmed, have them try in an incognito window.
If it still fails, send me the exact error text and I'll dig
deeper on our end.

Variant phrasings

sign in with google not working support

Steps 1 through 3. Google-side errors usually mean the wrong Google account is active in the browser, especially with multiple profiles.

SAML login loop troubleshooting

Steps 1 and 3. Loops are almost always a stale provider session or a clock skew between the provider and your servers.

new employee cannot log in with SSO

Step 4 first. It is the app assignment, every time, until proven otherwise.

Why it happens

SSO outsources the "who is this person" question to the customer's provider, which means your login page is now dependent on a system you cannot see into. Any mismatch, expired assignment, stale session, or config drift on their side surfaces as your login being broken. The user blames your app because your logo is on the button, but the fix usually lives in their admin console.

Edge cases

• User has two accounts with similar emails: the provider may be sending the personal one while your app expects the work one. Check the email in your user record against what they typed.
• SSO worked until the company changed providers: the connection on your side may still point at the old one. This is a reconfiguration, not a user bug. Escalate.
• Intermittent failures for everyone: look at your own side. Provider outages and expired certificates on your end hit all users at once.
• The error says the user does not exist in your app: they may need an account created first before SSO can link. Check whether your setup auto-provisions or needs manual invites.
• IT insists everything is fine on their side: ask for a screenshot of the user's app assignment and a fresh timestamped attempt. "Fine" without evidence is not a diagnosis.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_MD2FXfjpVRytIw0tzfTRYA

Resolved from the public thread: https://vectle.com/posts/pst_MD2FXfjpVRytIw0tzfTRYA

Thread query: how to troubleshoot SSO login failures for users

TL;DR: SSO failures are a three-way handshake between the user, your app, and their identity provider, and the error almost always lives on the provider side. Read the actual error text instead of guessing, check the email-domain match first, and learn the sentence that hands the ticket to their IT admin cleanly. Half your job here is knowing what is not yours to fix.