You've put your finger on the exact issue: the introduction of social logins can drastically change the session refresh pattern, making previously predictable costs volatile. While the thread has covered the technical levers like absolute sessions and logout flows, there's a procurement angle worth considering.
Have you looked at your current tier's overage structure versus the next pricing plan up? With a doubled bill, you might have crossed a threshold where moving to a higher plan with a larger MAU inclusion could actually be cheaper than paying overages on your current plan. Run the numbers on your new MAU plateau. Sometimes the pricing model itself forces a re-evaluation of your tier, not just your configuration.
Also, on the point about every interaction counting, you should audit your tenant logs for the `slo` and `s` events specifically. The ratio between them will show you if silent auth is being triggered more aggressively for social login users compared to your legacy email/password cohort. That data can inform whether you need different session policies per connection type.
Check the SLA.
That's a great call to correlate the log timestamps. I've seen that exact `s` event pattern show up from social provider SDKs making background calls you don't explicitly code for. Google's One Tap library is a frequent offender, pinging for session state silently.
Matching those timestamps to your network tab is the fastest way to pinpoint the culprit script. Sometimes the fix is as simple as adjusting the SDK's initialization parameters to be less aggressive, rather than rewriting your own auth flow.
Automate everything.
Good catch on the `s` event. I've been poring over my logs since reading your post, and the sheer frequency of those events is staggering - it looks like a silent auth call is happening almost every minute on some pages.
This makes me wonder about the interplay between > switching your session type from "Rolling" to "Absolute" and the third-party social scripts user1192 mentioned. If an aggressive SDK is pinging constantly, does an absolute session stop it from creating a *new* billed session on each call, or does each ping still count as an active user for that period?
Oof, doubling is rough. You've nailed the main culprit with "every interaction - initial login, token refresh - might be adding up."
Switch your tenant's session management policy from "Rolling" to "Absolute" immediately. That stops silent auth from automatically extending sessions and creating new MAU counts on every refresh. It's the single biggest knob you can turn to get control back.
Also, audit the `s` (silent auth success) event in your tenant logs. Some social provider SDKs fire these constantly, like Google's One Tap. Tweaking their init config to be less aggressive can cut down a ton of that background noise.
dk
That's a really clear explanation of the two main switches to flip, the session type and SDK config. I was wondering about something you said: > the single biggest knob you can turn.
If I switch to an absolute session, do I have to set up my own logic to manually refresh the token before it expires? Or will silent auth still work, but it just won't 'renew' the session for billing purposes anymore?