Platform
Admin dashboard
The dashboard opens on Home, which answers two questions: is everything okay, and how are your apps being used. The Activity page, next to it in the sidebar, is the account's activity log: every sign-in, failed sign-in, team change and SCIM provisioning event. See Audit logs for what it records and what each event means.
Home
Home covers every tenant in the account. Use the two menus at the top to narrow it to one tenant and to choose how far back it looks: the last 24 hours, or the last 7, 14 or 30 days. Both choices are part of the page's address, so you can bookmark or share a narrowed view. Days start at midnight in your browser's time zone, and the last day is today so far.
Needs attention
When something needs you, Home lists it first. Nothing is stored: the list is worked out each time you open Home, and an item goes away once its cause is fixed. Items can't be dismissed. Each one links to the place where you fix it.
| Item | Shown when | Links to |
|---|---|---|
| An app has no working secret | The app uses a client secret, and every secret it has has expired (or it has none) | The app's page, to add a secret |
| A client secret is about to expire | It expires within 14 days and the app has no other secret that lasts longer | The app's page, to add a secret |
| A custom domain isn't verified | It was added more than 24 hours ago and isn't serving yet | The tenant's Domain tab |
| An email domain isn't verified | It was added more than 24 hours ago and isn't verified yet | The tenant's Email tab |
| The Sign-in hook is failing | A call failed in the last 24 hours | The hook's Calls tab, showing failed calls |
| An app has errors | It had an App error, such as a failed code exchange, in the last 24 hours | Activity, showing that app's errors from the last 24 hours |
| Many failed sign-ins for one email | 10 or more failed sign-ins for the same email within one hour, in the last 24 hours | Activity, showing that email's failed sign-ins from the last 24 hours |
The thresholds are fixed.
The numbers
- Users: every user in the account, or in the chosen tenant.
- New users: users created in the range.
- Sign-ins: sign-ins in the range, successful or not.
- Failed sign-ins: the share of those sign-ins that Authalla refused.
New users, sign-ins and failed sign-ins are compared with the period of the same length just before. Each number opens the list behind it, filtered the same way: Users opens Users, New users opens Users showing only those created since the range started, Failed sign-ins opens Activity at every sign-in with a refused attempt since then, and Sign-ins opens Activity's sign-ins since then, the list the number is drawn from. That list also holds events the number doesn't count, such as sign-outs, and shows each sign-in as one row however many attempts it took. Show all time above the list removes the start of the range.
Home counts every attempt. A successful sign-in counts once, and each attempt Authalla refused counts once as a failed sign-in, even when the user got in on a later try: five wrong PIN codes followed by the right one are five failed sign-ins and one successful one. Repeated tries are what a guessing attack, or a sign-in page that confuses people, looks like, so they aren't hidden behind the success that followed. Activity still shows that sign-in as one row, which says how many attempts failed, and the Failed sign-ins number opens Activity at every row with a refused attempt. These aren't counted:
- token refreshes, which apps make on their own
- impersonation, which is team activity
- an attempt the user cancelled at the identity provider, for example by closing Google's consent screen
- the success of a sign-in that ended in an App error: the user signed in, but the app never got its tokens, for example because it sent a redirect URI it hasn't registered
- failures past the first 20 in one sign-in, so one browser repeating a bad code or link can't inflate the numbers without end
An App error, such as an app failing to exchange its code for tokens, doesn't make a sign-in fail: the user did nothing wrong. It shows under Needs attention instead, and Activity's App error outcome lists the sign-ins it stopped.
Below the numbers, a chart shows successful and failed sign-ins per day (per hour for the last 24 hours), and two lists split the sign-ins by app and by sign-in method. An app in the list opens its sign-ins on Activity since the range started.
Sensitive changes
The last five sensitive changes: impersonation, Sign out everywhere, suspending or changing a user, client secrets created or expired, team members invited, removed or given a new role, account API keys, and changes to Hooks and connections. See all opens Activity filtered to them.
Your first sign-in
Until someone signs in to one of your apps for the first time, Home shows three steps instead of the numbers: create an app, add its redirect URI, and sign in once. Each step is ticked off when it's done, and the steps go away after the first sign-in.
A user's sign-ins
Open a user and select the Sign-ins tab to see how that user gets in:
- Linked identities: every connection the user has signed in through. Each row shows the connection (Google, or an enterprise OIDC or SAML connection), the email and ID the identity provider knows the user by, and when the user first and last signed in through it. Profile shows what the identity provider sent at the last sign-in, which helps when checking attribute or claim mappings. An identity whose connection was deleted stays listed as Deleted connection.
- Passkeys: the user's registered passkeys and when they last signed in with one.
- Email: when the user first and last signed in with a magic link or a PIN code. Only methods the user has used appear.
See activity opens Activity filtered to the user: each of their sign-ins, failed ones included.
Email and passkey sign-ins are recorded from September 2026. Linked identities show their first and last use from when they were created.