@mark-robustelli Thanks for your reply, Mark. If I manage to make it, I’d love to show you how I made it and what it looks like.

I am building a real-time dashboard and reporting system that shows user online/offline status and idle time.

Current Setup

I consume Kafka events from our authentication server that include:

• list itemLogin success (user authenticated)

• list itemToken refresh (user’s access token refreshed)

• list itemToken revoke (logout or manual revocation)

Access tokens are short-lived JWTs, refresh tokens have a longer lifetime.

I need this tracking for two purposes:

Real-time dashboard — show current online/offline/idle status.

Historical reporting — store session history with start time, end time, and idle time.

The Challenge

If a token expires naturally (user closes browser, loses connection, or simply stops using the system) and there’s no explicit logout/revoke event, I do not receive any event from the auth server.

This means users could appear "online" indefinitely unless I detect inactivity/expiry myself.

I also want to calculate idle time — periods where the user has a valid session but is not actively refreshing tokens.

Requirements

Detect when a user should be marked offline if:

No token refresh occurred before the access token expires.

The refresh token also eventually expires.

Detect idle state if there is no activity for a configured threshold (e.g., 15 minutes), even if the token has not yet expired.

Keep a real-time store (e.g., Redis, Kafka Streams state store) for dashboard queries.

Persist session history (start time, end time, idle periods) in a database for reporting.

My Questions

What is the best approach to handle natural token expiry detection without explicit events?

How should I design the state tracking logic so it works for both real-time dashboard and historical reporting?

Would using Redis TTLs or periodic scans be better for detecting inactivity and expiry?

How should I manage the mapping between session IDs and tokens for accurate reporting, considering refresh events can issue new tokens for the same session?

Are there best practices for idle detection in systems relying on token events?

Any architectural patterns, code examples, or practical advice would be appreciated.

Hi @mark-robustelli, thanks for your reply. I need an API that logs out a user, but apparently that’s not possible. Is there any way or approach to log someone out.

Hi everyone,

Is there a way to force logout users in FusionAuth using only their user ID?
I want to invalidate all their active sessions without needing their refresh tokens.

Thanks in advance for any help!

Thanks for your response, @mark-robustelli. Apologies — it was my mistake. I was supposed to use the instance ID of the previously taken action, not the User Action ID.

Hi @mark-robustelli,

I initially tried the Take an Action on a User API (https://fusionauth.io/docs/apis/actioning-users#take-an-action-on-a-user) with the following request body:

{
"broadcast": true,
"action": {
"actioneeUserId": "dd0e31c9-a7cb-3597-bff1-45d3b13255ad",
"actionerUserId": "dd0e31c9-a7cb-3597-bff1-45d3b13255ad",
"comment": "This user is being a jerk",
"emailUser": true,
"expiry": 1771586483322,
"userActionId": "dfc52db9-ff76-4606-92b6-c7419ae5fe6c"
}
}
Afterward, I attempted to cancel the action using the Cancel a Previously Taken Action API, but I received a 404 response.

I used the following actionId:
dfc52db9-ff76-4606-92b6-c7419ae5fe6c, which does exist.

Could you help me understand what might be going wrong?

Thanks!

Hi, I am currently using FusionAuth version 1.53.2. When I try to cancel actions that are in progress using the API, it returns a 404 error. I've read through all the release notes but didn't find any mention of this issue. Is this a known bug, or am I implementing the API call incorrectly?