## TL;DR
Hourly logouts are either the session policy (a 60-minute timeout working as designed) or a bug (token refresh failing, clock skew, or session conflicts). Check the policy first: if the timeout is 60 minutes, explain it. If the policy is longer, triage the bug: token refresh failures, wrong device clocks, and multiple sessions invalidating each other. Do not call it a bug until you know the policy.

## The query

```text
app logs me out every hour: support triage
```

## Use this when

- Users report being logged out hourly
- Session bug triage
- Writing login troubleshooting documentation
- "Keeps logging me out" tickets

## Not for

- Changing session timeout policy
- Auth code debugging
- SSO configuration
- "Remember me" feature design

## Steps

### 1. Check the actual session policy

What is the configured timeout: 60 minutes of inactivity, 60 minutes absolute, or longer. "Every hour" matching the policy exactly means it is working as designed. Get the policy before touching anything else.

Expected output: the configured timeout, confirmed.

### 2. Distinguish inactivity from absolute timeouts

Inactivity timeout resets on activity; absolute does not. A user actively working who gets logged out hourly has an absolute timeout or a bug. Ask whether they were active when it happened.

Expected output: timeout type identified.

### 3. Check token refresh

Modern apps silently refresh tokens. If refresh fails (network blips, revoked refresh token, clock skew), the session dies at the access-token lifetime, often hourly. Check the device clock first: wrong clocks break token validation.

Expected output: clock correct; refresh path considered.

### 4. Check for conflicting sessions

Logging in on a second device or browser sometimes invalidates the first session, depending on the session policy. Ask about other devices. Single-session policies cause exactly this symptom.

Expected output: other sessions identified or ruled out.

### 5. Explain or escalate with evidence

Policy: explain the timeout and offer "remember me" or trusted-device options if they exist. Bug: escalate with the evidence (policy says 8 hours, user logged out hourly while active, clock correct).

Expected output: explanation or an evidence-backed escalation.

## Template: the triage reply

```text
Hourly logouts have a few distinct causes, [Name]. Let me narrow it down:

1. Were you actively using the app when it logged you out, or had you stepped away? (This tells me whether it is an inactivity timeout or something else.)
2. Is your device clock set to automatic? A wrong clock breaks login sessions.
3. Are you signed in on other devices or browsers at the same time?
4. Does it happen roughly every 60 minutes even while you are active?

Our session policy is [policy]. If what you describe does not match it, I will escalate this as a bug with everything you tell me.
```

## Variant phrasings

### keeps getting logged out

Steps 1 and 2. Policy check, then timeout type.

### session expires while active

Steps 3 and 4. Token refresh and conflicting sessions.

### logged out every 60 minutes

Step 1 first. If the policy is 60 minutes, that is the answer.

## Why it works

"Every hour" is suspiciously precise, which makes it diagnosable: precise intervals point to configured timeouts or token lifetimes, not random bugs. The policy-first approach prevents debugging a working system, and the evidence ladder (clock, sessions, activity) catches the real bugs efficiently.

## Edge cases

- The policy recently changed: users experience it as a bug. Acknowledge the change.
- VPN IP rotation invalidating sessions: some systems tie sessions to IP. Ask about VPNs.
- Corporate MDM wiping app data URIs the app is fine; the device management is clearing it.
- Refresh failing only on one platform: escalate as a client bug with the platform specified.

## Provenance

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