At a glance
The count of distinct Supabase Auth users who held an active session in the last 24 hours. It is the demand-side companion to the auth health alerts: a steady, healthy number means returning users are signing in and staying signed in. A sudden dip, with no corresponding rise in sign-in failures, points at a session, token, or traffic problem rather than a credential one.
What it tracks
This card reads Supabase Auth (GoTrue) session data and reports the number of distinct users with at least one active session in the trailing 24-hour window. It is the rolling daily-active count for authenticated users of the project, drawn from theauth.sessions data and the project metrics endpoint. The window is 24 hours so the figure smooths out the natural daily rhythm of logins and gives a stable day-over-day baseline to trend against.
Read it as a baseline, not an alert: there is no fixed threshold (the alert column is blank). Its value is in the comparison. Hold it next to Auth Sign-In Error Rate %: if active users fall while the error rate climbs, customers are being locked out by a credential or provider fault. If active users fall while the error rate stays flat, the cause is elsewhere (a traffic drop, a token-expiry or session-length change, or a Realtime disconnect storm dropping live sessions). A healthy, growing number alongside a low error rate is the all-clear for the auth layer.
Reconciling against the source
Confirm the figure in the managed-service console under Authentication → Users (filter by last sign-in), or query theauth schema directly: SELECT count(DISTINCT user_id) FROM auth.sessions WHERE created_at >= now() - interval '24 hours';. Minor differences come from window alignment (rolling 24 hours vs a calendar day) and the metrics scrape interval.