Monitoring authentik with Prometheus and Grafana: what to watch and why
Most teams learn that authentik has a problem when a user cannot sign in, and by then every application behind it is affected. Because authentik is the sign-in path for many applications, a stalled worker or a failing server shows up first as broken logins across unrelated systems. The platform team needs to watch each part separately: the server container, which runs core and the embedded outpost, the worker container, which runs background tasks, and the PostgreSQL database that holds configuration and data. Each has its own health signal. Confirm the live and ready health endpoints for your version in the authentik documentation, the worker healthcheck command you can run inside its container, and the metrics endpoint on port 9300. A check that only tests the login page will miss a worker that has stopped processing jobs.
Prometheus is the usual way to collect those signals over time. It pulls metrics over HTTP from the targets it discovers or is configured with, and it keeps them in a local time series database with a default retention of 15 days. That local store has no clustering or replication, so the Prometheus host needs the same care as any single-node database, and longer retention depends on remote write to external storage. Alertmanager receives alerts from Prometheus and handles grouping and silences, and Prometheus should point at every Alertmanager instance. Grafana reads from Prometheus to draw dashboards. For production use, Grafana's configuration should live in PostgreSQL or MySQL, since its installation docs say SQLite does not scale for production. Confirm that any example dashboard matches your authentik version before you import it.
Set this up before go-live so the first incident is visible. Three moments make monitoring necessary. Before go-live, you need a baseline of healthy servers and workers to compare against later. After you scale servers or workers, process counts and database connections change, and the PostgreSQL connection count deserves its own panel, because the authentik 2025.10 release notes warned of roughly 50% more connections after upgrading, when Redis was removed and its work moved to PostgreSQL. Before you rely on background tasks such as LDAP sync, you need to know when a worker stops, because a sync can fail quietly while sign-in still works. Ask your team to confirm which metrics your release exposes and which alerts will fire when the worker queue stops moving.
Which health signal to use for each authentik component
The server container runs the core application together with an embedded outpost, as described in the architecture documentation. It is usually the first component users notice when something breaks, so it needs both a liveness signal and a readiness signal. Liveness tells the orchestrator the process is running. Readiness tells it the instance can serve requests. Confirm the exact live and ready endpoints, and their expected responses, for the version you run before you write probe configuration.
- Liveness probe: use it only for restart decisions. A failing liveness check while the database is reachable often points to a stuck process or resource limits.
- Readiness probe: use it to remove an instance from load balancing when it cannot serve requests, including when it cannot reach PostgreSQL.
- External status codes: measure HTTP status and latency at the reverse proxy or load balancer, because internal probes can pass while users see login errors.
- Metrics endpoint: the topic plan assumes metrics on port 9300. Confirm which processes expose that port in your version and that Prometheus can reach it.
- Embedded outpost: if you use embedded proxy providers, treat the outpost as part of the server for alerting and check its connection state.
Check that probe paths in your load balancer and Kubernetes manifests match the release you deployed, because endpoints can change between versions.
The worker container runs background tasks. A healthy server can hide a stalled worker, because logins still work while scheduled work, source synchronization and other queued jobs stop. authentik provides a worker healthcheck command that you can run inside the container to test whether the worker process responds. Pair that check with a view of the task backlog, since a growing queue is often the first sign of trouble. Confirm the command name and its exit behavior in the documentation for your version.
- Healthcheck command: run it as an exec probe or from your container runtime, and alert on a nonzero exit code.
- Task backlog: track pending and failed task counts in the admin interface or the database. A rising backlog with a passing healthcheck usually points to throughput limits, not a dead process.
- Directory sync jobs: source synchronization runs in the worker, so missed syncs show up here before users report missing accounts.
- Restart loops: repeated restarts usually point to startup errors such as migrations or configuration problems rather than load.
- Database load from tasks: the 2025.10 release notes moved tasks into PostgreSQL, so a large backlog also adds database load. Watch both signals together.
After each upgrade, confirm that the worker healthcheck and backlog alerts still fire as expected, because a changed container layout can silently break an exec probe.
Outposts handle traffic for certain provider types, such as proxy providers used for forward auth and LDAP providers, and they connect back to the core. The provider list shows which provider types exist in your version. A healthy server can still leave protected applications unreachable or directory binds failing, so each outpost you run needs its own health checks. Start with the outpost connection state in the admin interface, then check the outpost's logs and metrics. Confirm which outpost types your deployment runs and where each one exposes its metrics.
- Connection to core: an outpost that has lost contact with the server stops receiving configuration updates. Check this state first.
- Proxy outposts: monitor HTTP status and latency for protected applications at the reverse proxy, because forward auth failures appear to users as application errors.
- LDAP outposts: track bind success and failure rates and connection counts, since directory-dependent services fail when binds fail.
- Separate scrape targets: give each outpost its own scrape target and alert, so one healthy server does not mask a dead outpost.
- Version alignment: confirm in the upgrade documentation whether your version requires outposts to match the core version and in what order to upgrade them.
Run a test login through each protected application on a schedule, because an outpost can report as connected while a specific application route is broken.
authentik stores its configuration and data in PostgreSQL, as described in the architecture documentation. Since the 2025.10 release, caching, tasks, sessions and WebSocket functions also run on PostgreSQL, because authentik no longer uses Redis. The 2025.10 release notes warned of roughly 50% more PostgreSQL connections after upgrading, so connection count is the first signal to watch. Measure a new baseline after each upgrade and set alerts with headroom below your configured limit.
- Connection count: compare active connections with the configured maximum and with any connection limit on a pooler.
- Query latency: slow queries appear as slow logins and admin pages before they cause an outage.
- Storage growth: event and task data grows over time, so track disk use and table size.
- Pooler saturation: if you run a connection pooler, watch clients waiting for a connection as well as open server connections.
- Managed or highly available database: monitor replication lag and failover events if you use them. The Kubernetes guide says the PostgreSQL bundled with the chart is for demonstration and test environments.
Compare current connection counts against the baseline you recorded after the upgrade, and confirm the connection behavior for your version in the release notes before you set thresholds.
Setting up health checks and metrics scraping step by step
This sequence connects authentik's server and worker health checks and metrics endpoint to Prometheus, then to a Grafana dashboard and a test alert. When it is finished, you can see every authentik component as up, query its metrics, and confirm that an alert reaches the team that needs it.
Confirm the deployment method and versions
Your platform team confirms whether authentik runs on Docker Compose or the Helm chart, and checks that the running version sits on a line that receives security fixes in the authentik security policy. The Compose guide is positioned for test setups and small-scale production, so note any gap between that and your requirements. Record the Prometheus and Grafana versions you plan to run, using their release pages. Done when every server, worker and outpost container or pod shows as running, and you have a written list of hosts and namespaces to monitor.
Enable the metrics endpoint for Prometheus only
Enable the metrics endpoint on port 9300 for the authentik server, worker and each outpost, using the configuration keys in the authentik install documentation for your method. Then restrict access at the network layer, such as a host firewall, a security group or a Kubernetes network policy, so only the Prometheus host or pods can reach that port. Do not publish port 9300 through your public reverse proxy or ingress. Done when a request to port 9300 succeeds from the Prometheus host and fails from a workstation or another network segment.
Check the live, ready and worker health endpoints
Before adding anything to Prometheus, confirm that authentik answers its health checks. Call the live and ready health endpoints on the server, and run the worker healthcheck command inside the worker container or pod. Confirm the exact paths and command names in the authentik documentation for your version, since they change between releases. If a check fails, fix the database connection or container startup first, because scraping a component that is not healthy only produces noise. Done when the live and ready checks return success and the worker healthcheck exits cleanly.
Add scrape jobs for server, worker and outposts
Edit the Prometheus configuration to add one scrape job for the server, one for the worker and one for each outpost group. Use static targets for a small Compose setup, or Kubernetes service discovery for a Helm deployment so that new pods are picked up without edits. Give each job its own label, so dashboards and alerts can separate server, worker and outpost data. Outposts that run outside the server need their own addresses on port 9300. Reload Prometheus, then open the targets page. Done when every authentik target listed in your plan shows as UP with a recent last scrape time.
Query authentik metrics in Prometheus
Open the Prometheus expression browser and run a simple query that returns authentik series, such as a count of series filtered by your server job label. Confirm that each series carries the job and instance labels you configured, so you can tell which component produced it. Review retention next. Prometheus keeps 15 days of data by default, stores it on a single node that is not clustered or replicated, and can be configured by time or size. Decide whether that retention matches your needs and whether remote write to long-term storage is required. Done when your query returns results for each job and you have written down the retention setting.
Connect Grafana and import the example dashboard
Add Prometheus as a data source in Grafana, either through a provisioning file loaded at startup or through the Grafana interface. Import the example authentik dashboard, then point its data source variable at your Prometheus instance. For production, confirm that Grafana uses MySQL or PostgreSQL for its configuration database, because SQLite is not suitable for production use. If you manage Grafana as code, store the data source and dashboard files in version control. Done when the dashboard's panels show data for the server, worker and outposts, and none of them report no data.
Add and test an alert through Alertmanager
Create a Prometheus alert rule that fires when an authentik target is down, based on the up metric for your authentik jobs. Set the hold period to a value your team chooses, then point Prometheus at every Alertmanager instance and route the alert to a test receiver. Trigger the condition on purpose by stopping a non-production worker, and wait for the alert to appear in Alertmanager and reach the test receiver. Restart the worker, confirm the alert resolves, and then either delete the test rule or replace it with your production routing. Done when the test notification arrives and the resolved notice follows.
Monitoring options and when each fits
This table compares the monitoring setups an authentik team is likely to choose between, from a small Compose host to Kubernetes and a shared Prometheus. Read each row against your platform, your retention needs and how many people will be paged, and treat the last rows as the decisions that change most after go-live.
| Option | Best fit | Main trade-off | What to confirm first |
|---|---|---|---|
| Compose health checks with a small Prometheus | Single-host test or small production authentik on Docker Compose | Prometheus runs on one node with local storage that is not clustered or replicated | Which host runs Prometheus, and who restores it if the host fails |
| Kubernetes probes with Prometheus Operator and ServiceMonitor | authentik on the Helm chart where the cluster already runs Prometheus | Scrape configuration and alert rules are managed as Kubernetes objects, so cluster skills are required | Whether the cluster already has Prometheus Operator and which namespace scrapes port 9300 |
| Managed or external Prometheus with remote write | Teams that need longer retention or central monitoring across several services | Samples leave the host, so network path, credentials and the receiving platform's terms need review | Retention period, data residency and who owns the remote storage system |
| Local Prometheus retention (default 15 days) | Short operational history for troubleshooting recent incidents | Default retention is 15 days, configurable by time or size, and older data is lost without remote storage | Whether audit or capacity reviews need history beyond the local window |
| Grafana with PostgreSQL or MySQL | Production or high availability dashboards and alerting | Requires a database to run and back up, and HA needs extra setup for alert notifications | Database engine version and whether the team already operates it |
| Grafana with SQLite | Test environments and evaluation only | SQLite does not scale for production or high availability, according to the Grafana installation docs | Whether a move to MySQL or PostgreSQL is scheduled before go-live |
| Single Alertmanager instance | Small environments with one team receiving alerts | No redundancy, so a failed Alertmanager silently stops notifications | Who receives alerts when the instance is down |
| Alertmanager cluster | Production systems where alert delivery must survive one node failure | Each Prometheus must point at every Alertmanager instance, not a load balancer, and cluster flags need configuration | Whether the team can operate and test the cluster flags before relying on them |
Alerts worth setting for authentik
These alerts cover the components that fail first in a running authentik deployment: the server, the worker, outposts, scrape collection and the PostgreSQL connection pool. Set each threshold from the baseline you record in your own environment, because Prometheus values reliability over precision and a noisy alert gets ignored. Treat the list as a starting point to refine after the first few weeks of data.
Server not ready
Alert when the readiness endpoint fails for a server container over a sustained window, not on a single failed probe. A failing ready check usually means the server cannot reach PostgreSQL or is stuck during startup, so users see login errors even while the live endpoint still answers. Check the server logs and the database connection first, then confirm that load balancers are removing the instance from rotation.
Worker health or backlog growing
Alert on a failing worker healthcheck and on a task queue that keeps growing between evaluations. Background work such as email delivery, LDAP syncs and event handling runs in the worker container, so a stalled worker can fail silently while logins still succeed. Compare the backlog trend against your normal load and check the worker logs before you scale anything.
Outpost disconnected
Alert when an outpost stops reporting in, because forward auth and LDAP or RADIUS clients that depend on it will fail without an obvious error in the application. Outposts are a separate deployment from the core server in many layouts, so a disconnected outpost can exist while the admin interface looks healthy. Confirm the outpost can reach the authentik server and that its token has not been rotated.
Scrape target down
Alert when Prometheus cannot scrape the authentik metrics endpoint on port 9300. A missing scrape turns every other panel and alert into a silent gap, so this check protects the rest of the rule set. Confirm that the metrics endpoint is reachable from Prometheus, that network policies allow it, and that the target labels match your server and worker containers.
PostgreSQL connections nearing limit
Alert when the PostgreSQL connection count approaches the configured maximum or your pooler's limit. The 2025.10 release notes warn of roughly 50% more PostgreSQL connections after upgrading, since authentik moved caching, tasks, sessions and WebSocket functions into the database. Track connections by source against the pool size you set, and review this alert again after each authentik upgrade.
Certificate expiry and metric gaps
Alert on certificates that expire within a window you choose, and on gaps in the authentik metric series that exceed your scrape interval. Expired TLS certificates on the reverse proxy stop sign-ins for every application at once, and metric gaps can hide an outage that the other alerts would have caught. Record the certificate sources and renewal process so the alert has a clear owner.
Protecting the metrics endpoint and the monitoring stack
Treat the metrics and health endpoints as internal interfaces, not public ones. Responses from port 9300 and the health endpoints can reveal the authentik version and details about internal state, which helps an attacker decide what to target. Place port 9300 on a network segment that only the Prometheus servers can reach, using firewall rules, security groups or a Kubernetes network policy, and confirm from outside that segment that the port does not answer. Keep the live and ready health endpoints on the same restricted path wherever your load balancer allows it, and check which of them your external monitors need before you close anything.
Prometheus has its own security model, and the Prometheus security documentation is explicit that it does not provide built-in authentication or encryption for its own endpoints. Control access at the network layer, and where you need authentication or TLS in transit, confirm the approach your Prometheus version supports and your scrape configuration requires, using the Prometheus security model as the starting point. Apply the same discipline to Alertmanager and to any remote write target, since all of them hold operational data. Grafana is the component most likely to be exposed to people, so harden it with the Grafana security hardening guidance: secure and SameSite cookies, a Content Security Policy, hiding the version from unauthenticated users, requiring authentication for the metrics endpoint and domain verification against DNS rebinding.
Plan Grafana sign-in as a separate decision. The Grafana authentication documentation lists LDAP, generic OAuth and other providers as available in every edition, but SAML, team sync, active sync and SCIM provisioning are available only in Grafana Enterprise and Grafana Cloud. If your standard is SAML sign-in to Grafana through authentik, that route requires Grafana Enterprise or Cloud, while OAuth or OIDC sign-in works on the open-source edition. Confirm which Grafana edition and authentication method you will run before you publish dashboards, and record the decision with the team that owns the monitoring stack.
Security and operational considerations for the monitoring stack
The monitoring stack for authentik exposes sensitive operational data, so it needs the same scrutiny as the identity service it watches. The cards below cover where metrics are reachable, how scrapers authenticate, how Grafana users sign in, and how to keep authentik, Prometheus and Grafana patched on their own schedules.
Network exposure of metrics
authentik serves metrics on port 9300, and that endpoint describes users, sessions, workers and configuration state in ways an attacker could use for reconnaissance. Keep the port on a private network segment reachable only by the Prometheus servers, and confirm that your reverse proxy and load balancer rules do not publish it to the internet. Check this from outside your network after every change to ingress rules.
Credentials for scrapers
Prometheus must reach the metrics endpoint, and any authentication you add should be a dedicated, least-privilege credential rather than a shared administrator token. Decide how the scraper's secret is stored, rotated and revoked, and whether Prometheus config files containing it are readable only by the service account. Record which identity the scraper uses so audit reviews can tell scraper traffic from people.
Grafana authentication options
Grafana can sign users in through LDAP, generic OAuth, an auth proxy or JWT in every edition, so the dashboards do not need a separate local account store. SAML, team sync and SCIM provisioning are limited to Grafana Enterprise and Grafana Cloud, so confirm early whether your group-based access depends on those features. Test each login path and the local admin account before go-live.
Tracking authentik supported releases
The authentik security policy lists 2026.5.x and 2026.8.x as the lines receiving security fixes, and security releases are announced at least 24 hours ahead. Subscribe to the release feed, schedule a review window for each announcement, and note which line your deployment runs. A monitoring dashboard is only useful if the identity service it watches stays on a supported line.
Patching on separate cadences
Prometheus, Grafana and authentik each publish releases on their own schedules, so a single maintenance window will not cover all three. Prometheus minor releases stop receiving bug fixes after six weeks, while long-term support lines get fixes for one year. Assign an owner to each component, track end-of-life dates, and test upgrades in a non-production copy before applying them.
Questions teams ask before monitoring authentik
What does it cost to monitor authentik with Prometheus and Grafana?
Prometheus and Grafana are open-source projects with no paid edition of the software itself, so the cost comes from the infrastructure they run on, the storage for metrics and dashboards, and the staff time to build, operate and patch them. Prometheus keeps its data on local disk by default with 15 days of retention, so storage grows with the number of series and the retention you choose. Grafana needs a database for production: PostgreSQL 12 or later, or MySQL 8.0 or later. If you prefer a hosted option, Grafana lists a free tier, a Pro tier starting with a 19 US dollar monthly platform fee plus usage, and an Enterprise tier with a minimum commitment of 25,000 US dollars per year, according to its pricing page. When you request a quote, ask for the one-time build effort, the recurring hours for upgrades and alert tuning, and the storage sizing assumptions behind it.
How long does monitoring setup take, and what drives the duration?
The duration depends mostly on how many authentik components you expose, how your metrics collection already works, and whether a Prometheus and Grafana stack exists. A single Docker Compose host with one server and one worker is a smaller job than a Kubernetes cluster that also runs outposts in several locations. The main drivers are: confirming that the metrics endpoint on port 9300 is reachable from Prometheus, deciding how health checks feed your alerting, building and reviewing the dashboard, writing alert rules with thresholds your team agrees on, and wiring notifications to an on-call path through Alertmanager. Access approvals and change windows often take longer than the configuration itself. Ask for a fixed scope and written milestones before work starts.
Can our own team set up authentik monitoring without a partner?
Yes, if your team already runs Prometheus or Grafana and has someone comfortable with PromQL and container networking. The authentik health endpoints and the metrics endpoint are straightforward to scrape, and the Grafana provisioning model lets dashboards and data sources be stored as YAML or JSON files and version controlled. Teams without that experience usually struggle with three areas: sizing and retention of local Prometheus storage, which Prometheus does not replicate on its own, and alert design that avoids noise. Outside help is most useful for the initial design review and for building alerts that match your service levels. Whichever path you choose, confirm the metrics and dashboard details against the current authentik release you run.
What does the monitoring work need from our team?
Expect to provide four things before work starts:
- Access to the Kubernetes cluster or the Docker Compose host where authentik runs, with permission to change the scrape configuration and restart services in a planned window.
- Access to your existing Prometheus, Alertmanager and Grafana instances, or a decision on where to host new ones.
- A named dashboard owner who approves panels, data retention and access rights in Grafana.
- An on-call path that receives alerts, with a named escalation contact and an agreed response for each severity.
If you use a central Grafana, confirm how its authentication is configured. Grafana's authentication docs list LDAP, generic OAuth and other methods for every edition, while SAML and SCIM are limited to the Enterprise edition and Grafana Cloud.
How are Prometheus and Grafana upgrades scheduled?
Plan upgrades as a recurring task with a named owner, because the two projects follow different schedules. Prometheus starts a new minor release cycle every 6 weeks, and a minor release generally stops receiving bug fixes after those 6 weeks. For a longer support window, the long-term support line receives bug fixes for one year; the current line is 3.13, supported until July 31, 2027. Grafana publishes major releases once a year in April or May, minor releases every other month and patch releases at least monthly, with each minor release supported for 9 months. Schedule Prometheus and Grafana upgrades in a test environment first, then in production, and check the authentik release notes at the same time because metric names can change between authentik versions.
Is Prometheus reliable enough to alert on authentik outages?
Prometheus is built to be reliable for operational alerting, but its documentation says it values reliability over precision and is not a good choice where 100% accuracy is required, such as per-request billing. Its local storage is not clustered or replicated, so a single Prometheus server is a single point of failure for both data and alerts. Alertmanager can run as a cluster for high availability, and Prometheus should be configured to send alerts to every Alertmanager instance rather than through a load balancer. Ask whether you need a second Prometheus, remote write to long-term storage, or an external check that tells you when monitoring itself has stopped.
Which authentik monitoring signals should trigger alerts first?
Start with signals that show users cannot sign in or that background work has stopped. The health endpoints tell you whether the server and worker processes respond, and the worker healthcheck command confirms the worker container can run its check. The metrics endpoint on port 9300 provides data for dashboards and rules. Set alerts for failed health checks, sustained error rates on login paths and a worker that stops processing tasks. Treat thresholds as starting points and tune them against your normal traffic before paging anyone. Confirm the exact metric names and health paths against the authentik documentation for the version you run.
How DeployOpen scopes and delivers authentik monitoring
DeployOpen plans and implements self-hosted monitoring for authentik inside your own infrastructure, so the metrics, dashboards and alert routing stay in the cloud accounts, data centers or air-gapped network you already control. Before work starts, the scope is agreed in writing. That document names the components in scope (the authentik server and worker containers, any outposts, the PostgreSQL instance behind them, and the Prometheus, Alertmanager and Grafana stack that will watch them), the health and metrics endpoints to be scraped, the alert rules and notification channels, and the deliverables such as dashboards, runbooks and handover sessions. A quote follows from that written scope, so the cost reflects what your team asks for rather than a standard package.
Decisions that shape the scope are worth settling early. Ask whether Prometheus will run in your existing platform or as a new deployment, how long metric data must be retained locally and whether a remote write target already exists, and who receives alerts out of hours. Confirm whether your Grafana edition and authentication model match the controls you need for access to dashboards, since some Grafana features depend on the edition you run. Where your team lacks capacity, the scope can also cover the work that keeps monitoring useful over time, such as reviewing alert noise after each authentik upgrade.
Monitoring is not a one-time task. DeployOpen offers retainers for ongoing upgrades to the monitoring stack, continuous review of alert rules against new authentik releases, and periodic checks that scrape targets and dashboards still reflect the running environment. Ask any provider, including DeployOpen, to state in writing which versions are covered, how security fixes are handled, and who on your side approves changes to alerting. Certifications and partner status are not part of this offer, and any compliance evidence your auditors need should be requested from them directly.
