Your applications and services depend on Auth0. Monitoring Auth0’s health lets you report specific errors to customers or reduce user impact in case there’s an issue with Auth0. There’s many ways to monitor Auth0 and each approach complements the others. You should pick based on your needs and investment possibilities.

​
Synthetic transactions

The simplest approach to monitor Auth0:
  • Set up a periodic request to perform an authentication transaction.
  • If the request succeeds, Auth0 is working fine.
  • If the request fails, this may indicate:
    • an issue with Auth0
    • an issue specific to the tenant used for the synthetic transaction
    • or just a single failed request.
For synthetic transactions, use an environment as close to your production tenant configuration as possible. You may potentially even use the same production tenant. Since setting up synthetic transactions with redirect flows and third party providers can be tricky, using the Resource Owner Password Grant is recommended. This flow doesn’t involve browser redirects or require a UI. If you are using rules or custom database connection(s) or other extensibility points, the synthetic transaction(s) should be configured to utilize the rules and/or custom DB scripts to ensure that aspect of the system is working. Tools like Pingdom make setting up synthetic transactions a simple thing.

​
Check period

We recommend running synthetic transactions on one minute intervals. With this simple approach, that frequency won’t consume a lot of your Auth0 rate limit quota, while also providing timely responses.

​
Limitations of synthetic transactions

Synthetic transactions are a simple and inexpensive way monitoring an Auth0 tenant’s health. However, they do have some limitations:
  • Synthetic transactions do not represent your end user’s experience. Instead they give you a proxy metric for them.
  • Synthetic transactions might not use the same flows as your users.
  • They lack atomicity (typically run once a minute) and do not report on errors your end users might have seen.
If you are interested in getting more granular data read about Error Tracking and Metrics and Logs.

​
Error tracking

This approach is useful to track errors in existing calls to Auth0. It involves reporting errors whenever a call to Auth0 fails. Sentry is a tool commonly used for these cases, which works both on frontend and backend scenarios. This approach is useful because it allows you to know about real errors that your end users are experiencing. However, because you are only tracking errors (and not all requests) it is not possible to get an accurate perception of “how many” end users are affected: is it 1% or 5%? It also doesn’t require you to set up a separate “synthetic call”, which might consume part of your rate limit quota, especially if misconfigured.

​
Metrics and logs

This approach is useful if calls to Auth0 are performed from a backend you control. This is the case for:
Some observability products also allow you to report metrics/logs from frontend and mobile applications.
The approach consists of using metrics and/or logs to track error rates on calls to Auth0. Metrics/logs report error rates that accurately describe what end users are experiencing, without requiring you to set up a separate “synthetic call”, which might consume part of your rate limit quota, especially if misconfigured.

​
Alerting

Regardless of the monitoring approaches you use, it’s common to get an alert or page when errors happen at a particular rate. That rate depends on your application. When your team gets an alert from Auth0, we recommend adding a link to Check Auth0 Status to the alert payload/playbook. This will allow them to quickly check Auth0’s official status reporting channel to see if the issue is coming from Auth0 or your application/service.

​
Learn more