Sign-in activity is the log of authentication events: sign-ins, sign-ups, resets and second-factor use, with success or failure.

In Studio

Users & auth → Records → Sign-in activity. (For one person’s full activity, including account changes and the requests they make, see A person’s activity.) A table with columns: When, User, Event, Method, Result, IP, Device. Filter to failures to see attacks; open a person’s Activity tab for just their history. Use it for questions like:
  • “Did Ada really sign in from there?” → open her Activity.
  • “Is someone guessing passwords?” → filter Result: failed, look for one IP across many users.
  • “Which methods do people use?” → group by Method.

What is recorded

Each entry is one authentication event:

Event kinds

Sign-ups, verifications, account changes and session events are events you can subscribe to, and also appear in a person’s activity.

Read it from code

stats returns the number of users, how many are verified, have two-step verification on, or are disabled, sign-ups, sign-ins and failures in the last 24 hours, organizations, and how many people use each sign-in provider.

How long it’s kept

Sign-in history is kept for a period set by your plan, from 7 days on Free to 365 days on Scale. See Plans and limits. Export what you need to keep longer.

Alert on attacks

Don’t wait for the weekly review:
  • Subscribe a flow to session.reuse_detected (a stolen refresh token was replayed) and email your team.
  • Watch failures: a sudden rise in failed sign-ins from one address, or across many accounts, is password guessing or credential stuffing. Attack protection locks accounts and slows these down; the log tells you it’s happening.

Show people their own activity

A “Recent sign-ins” list on the account page lets people spot unfamiliar activity:
Each entry has kind, method, success, reason, ip, user_agent and at. A person only ever sees their own history.

A weekly security routine

  1. Review failed events for repeated failures against one account or from one address.
  2. List users with the MFA off filter who hold admin roles and ask them to enrol.
  3. Check locked accounts.
  4. Review user API keys and revoke ones you don’t recognise.
  5. Take a backup: import and export.

Attack protection

Lockouts.

Auth webhooks

Alert in real time.