An Auth0 login monitor should open your application, follow the redirect to Universal Login, authenticate a dedicated test user, return through the configured callback, and verify content that only a signed-in user can access. This covers more than an Auth0 status check because it also tests your application's callback, cookies, rules, and protected route.

Auth0's guidance says browser automation such as Playwright is the way to test the actual Universal Login pages. Direct token requests are useful for setting up other tests, but they do not prove that the user-facing login works.

Key takeaways

  • Use a dedicated Auth0 database user instead of an employee or customer account.
  • Assert every boundary: application, Auth0 tenant, callback, and protected page.
  • Use real UI login for one critical monitor and faster session setup for unrelated application tests.
  • Keep MFA, CAPTCHA, and enterprise identity-provider constraints explicit.
  • Start every scheduled run in a fresh browser context.

What does an Auth0 login monitor cover?

A successful Auth0 login crosses several systems:

  1. Your application creates a valid authorization request.
  2. Auth0 loads the correct tenant, connection, and Universal Login experience.
  3. The identity provider accepts the user.
  4. Auth0 redirects to an allowed callback URL.
  5. Your application exchanges or validates the response and creates its session.
  6. A protected route recognizes that session.

An HTTP request to the homepage covers none of those transitions. A direct call to /oauth/token covers the identity API but skips the browser, redirect URI, and application cookie.

Configure a safe test account first

Create a user in an Auth0 database connection reserved for automated checks. Give it the smallest application role that can reach the protected assertion page.

The account should have:

  • A mailbox controlled by the engineering team.
  • Credentials stored in the monitoring tool's encrypted environment variables.
  • No access to customer or production administration data.
  • A clear name or metadata field so analytics can exclude it.
  • A documented owner and rotation process.

Auth0 recommends separate environments for development, testing, and production. The production login monitor still needs a production account because a staging tenant cannot expose a broken production callback or rule.

A complete Auth0 login check in Playwright

The exact labels depend on the configured Universal Login experience. Identifier-first flows usually show the email step before the password step.

import { test, expect } from '@playwright/test'

test('Auth0 login reaches the protected account page', async ({ page }) => {
  test.setTimeout(90_000)

  await test.step('Start login in the application', async () => {
    await page.goto(process.env.APP_LOGIN_URL, {
      waitUntil: 'domcontentloaded',
    })
    await page.getByRole('link', { name: /log in|sign in/i }).click()
    await expect(page).toHaveURL(/auth0\.com|login\./)
  })

  await test.step('Complete Universal Login', async () => {
    await page.getByLabel(/email address|username/i)
      .fill(process.env.AUTH0_TEST_EMAIL)
    await page.getByRole('button', { name: /continue/i }).click()

    await page.getByLabel(/password/i)
      .fill(process.env.AUTH0_TEST_PASSWORD)
    await page.getByRole('button', { name: /continue|log in/i }).click()
  })

  await test.step('Verify the callback and protected page', async () => {
    await page.waitForURL(/\/account|\/dashboard/, { timeout: 30_000 })
    await expect(page.getByRole('heading', { name: /account|dashboard/i }))
      .toBeVisible()
    await expect(page.getByText(process.env.AUTH0_TEST_EMAIL)).toBeVisible()
  })
})

Use the Playwright locator guide to adapt the labels. Do not target Auth0's generated class names because a Universal Login update can change them without changing the user experience.

How do you handle the callback correctly?

Auth0 only returns users to URLs listed in Allowed Callback URLs. A typo, missing environment URL, or incorrect custom-domain configuration can break production login while Auth0 itself remains available.

Assert the final application URL, then assert a protected element. Either assertion alone is incomplete:

await expect(page).toHaveURL(`${process.env.APP_ORIGIN}/account`)
await expect(page.getByTestId('current-user-email'))
  .toHaveText(process.env.AUTH0_TEST_EMAIL)

The Auth0 application settings documentation describes the callback allowlist and warns against production callback entries that point to localhost.

If several redirects occur, use waitForURL() rather than a fixed delay. The waits and timeouts guide explains why a hard sleep creates intermittent failures.

Should you save Auth0 storage state?

Saved browser state is useful when a large CI suite needs an authenticated starting point. Log in once, save the context, then reuse it in tests that do not concern authentication:

await page.context().storageState({ path: 'playwright/.auth/user.json' })

Do not use saved state for the primary login monitor. It would skip Universal Login and hide an expired password, broken callback, or unavailable connection. Playwright's authentication guide covers storage-state reuse and multi-role setups.

How do MFA and enterprise SSO change the test?

Auth0's Resource Owner Password Grant can set up authenticated tests for a database connection, but Auth0 documents that it does not work when MFA is required or when the user is redirected to a social or enterprise provider.

For TOTP in an isolated test tenant, generate the current code from a test-only seed. Do not weaken a customer's SSO or MFA policy to make a scheduled script pass.

For enterprise SSO, coordinate a dedicated identity-provider user and a policy approved for non-interactive monitoring. If the provider requires a physical security key or device approval, monitor the flow up to that boundary and cover post-login application behavior with a separate session-based check.

How do you test sign-out?

Sign-out deserves its own short scenario because incomplete logout can leave application or Auth0 cookies active:

await page.getByRole('button', { name: /account menu/i }).click()
await page.getByRole('menuitem', { name: /log out|sign out/i }).click()

await expect(page).toHaveURL(/\/login|\/signed-out/)
await page.goto(`${process.env.APP_ORIGIN}/account`)
await expect(page).toHaveURL(/login|authorize/)

Run login and logout in separate tests if the combined journey approaches the Browser Check timeout.

How to use Hyperping for Auth0 login monitoring

1. Create a dedicated Auth0 user

Use a least-privilege database-connection user reserved for monitoring. Confirm its policy allows the approved automated login flow.

2. Store credentials safely

Add APP_LOGIN_URL, APP_ORIGIN, AUTH0_TEST_EMAIL, and AUTH0_TEST_PASSWORD under the Browser Check's environment variables.

3. Create the login check

Create a Hyperping Browser Check, paste the script, and update the application-specific protected assertion.

4. Test sign-out and session state

Add a separate sign-out check if session termination is critical. Each run starts in an isolated context, so state does not carry into the next scheduled execution.

5. Schedule regional runs

Choose regions that represent the user base. Send failures to the team that owns identity configuration, with the trace and video attached for diagnosis.

Keep one real login in the monitoring set

Direct tokens and stored sessions make application tests faster, but one scheduled journey should continue through the same Universal Login pages customers use. That is the check that catches broken redirects, tenant changes, and session-cookie failures.

See the end-to-end Playwright test ideas for related account scenarios and run Playwright locally before moving the script into Hyperping.