Monitoring Authelia with Vigilmon: SSO Availability, MFA Endpoint Health, Redis Session Store & SSL Certificate Alerts

Authelia is the self-hosted single sign-on and multi-factor authentication server that acts as a forward-auth middleware in front of every application in your stack. When Authelia goes down, every protected service returns 401 Unauthorized and your users can't log in — including yourself. When the Redis session store it depends on becomes unavailable, authenticated sessions expire immediately and authenticated users are kicked out silently. Vigilmon gives you external visibility into Authelia's health endpoint, the Redis session backend, your upstream identity provider, and the SSL certificates protecting every authentication flow so you know before your users do when something breaks.

What You'll Build

• An HTTP monitor on Authelia's health endpoint to detect process failures and startup errors
• An HTTP monitor on the Authelia authentication portal itself to catch routing and ingress failures
• A TCP check to verify the Redis session store is accepting connections
• Monitors for upstream LDAP/OIDC identity provider connectivity
• SSL certificate monitoring for the Authelia domain and any OIDC provider endpoints
• An alert runbook mapping Vigilmon findings to specific kubectl and docker remediation commands

Prerequisites

• Authelia v4.37+ deployed via Helm, Docker Compose, or bare-metal
• Redis configured as Authelia's session storage backend
• An Ingress controller (Nginx, Traefik) configured to use Authelia as forward-auth
• A Kubernetes cluster with kubectl access or Docker with docker compose access
• A free account at vigilmon.online

Step 1: Understand Authelia's Observability Surface

Authelia exposes an HTTP health endpoint and writes structured JSON logs. Before configuring external monitoring, verify what is reachable:

# Kubernetes: check Authelia pod status and restarts
kubectl get pods -n authelia

# Kubernetes: view live Authelia logs
kubectl logs -n authelia deployment/authelia --tail=50 -f

# Docker Compose: check running status
docker compose -f authelia/docker-compose.yml ps

# Test the health endpoint directly
curl https://auth.example.com/api/health
# Expected: {"status":"OK"}

# Test that the authentication portal loads
curl -o /dev/null -s -w "%{http_code}" https://auth.example.com/
# Expected: 200

# Check Redis connectivity from within the Authelia container
kubectl exec -n authelia deployment/authelia -- redis-cli -h redis.authelia.svc.cluster.local ping
# Expected: PONG

The key signals are:

• Health endpoint: /api/health returns {"status":"OK"} when Authelia is running and connected to all backends.
• Redis connectivity: Authelia fails to start or serve sessions if Redis is unreachable. Errors appear as redis: connection refused in logs.
• LDAP/OIDC failures: Authentication attempts fail with provider errors while the health endpoint may remain green.
• Pod restarts: High restart counts indicate misconfiguration or a dependency (Redis, LDAP) repeatedly disconnecting.

Step 2: Expose the Authelia Health Endpoint

Authelia's /api/health endpoint is accessible on the same port as the main portal (9091 by default). If Authelia sits behind an Ingress, the health endpoint is typically exposed at the same hostname:

# Verify health endpoint is accessible externally
curl https://auth.example.com/api/health
# Expected: {"status":"OK"}

# If not exposed, add a dedicated path to your Ingress

If you need to add an explicit health path to your Nginx Ingress:

# authelia-ingress.yaml (add health path if not already exposed)
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: authelia
  namespace: authelia
  annotations:
    nginx.ingress.kubernetes.io/proxy-buffer-size: "128k"
spec:
  rules:
  - host: auth.example.com
    http:
      paths:
      - path: /api/health
        pathType: Exact
        backend:
          service:
            name: authelia
            port:
              number: 9091
      - path: /
        pathType: Prefix
        backend:
          service:
            name: authelia
            port:
              number: 9091
  tls:
  - hosts:
    - auth.example.com
    secretName: authelia-tls

kubectl apply -f authelia-ingress.yaml
curl https://auth.example.com/api/health

Step 3: Create a Vigilmon HTTP Monitor for the Health Endpoint

1. Log in to Vigilmon → Add Monitor → HTTP.
2. URL: https://auth.example.com/api/health.
3. Check interval: 1 minute.
4. Response timeout: 10 seconds.
5. Expected status: 200.
6. Keyword: OK (present in the healthy JSON response).
7. Label: authelia health endpoint.
8. Click Save.

This monitor catches:

• Authelia process crashes or OOM kills that halt all authentication
• Redis session store connection failures that prevent Authelia from starting
• Misconfiguration errors after config file changes or Helm upgrades
• Certificate reload failures that crash the Authelia TLS listener
• Node evictions that temporarily remove the Authelia pod from service

Alert sensitivity: Set to trigger after 2 consecutive failures to suppress transient restarts during rolling deployments.

Step 4: Monitor the Authelia Authentication Portal

The health endpoint confirms the process is alive, but the authentication portal itself can fail due to Ingress misconfigurations, middleware registration errors, or upstream proxy chain breaks — while the health endpoint remains responsive. Add a second monitor on the portal root:

1. Add Monitor → HTTP.
2. URL: https://auth.example.com/.
3. Check interval: 2 minutes.
4. Expected status: 200.
5. Keyword: Authelia (present in the login page HTML title).
6. Label: authelia login portal.
7. Click Save.

This catches:

• Ingress routing failures where /api/health is served but / returns 502
• Theme or asset loading failures that break the login page rendering
• Traefik/Nginx forward-auth middleware misconfiguration that loops redirects
• CDN or reverse proxy caching issues returning stale error pages

Step 5: Monitor the Redis Session Store

Authelia uses Redis to store session data. If Redis becomes unavailable, authenticated users lose their sessions immediately, and new logins fail even if the Authelia process itself stays running. Monitor Redis directly with a TCP check:

# Find your Redis service address
kubectl get svc -n authelia | grep redis

# Test Redis connectivity manually
redis-cli -h redis.authelia.svc.cluster.local -p 6379 ping

In Vigilmon:

1. Add Monitor → TCP.
2. Host: redis.example.com (or the external Redis endpoint).
3. Port: 6379.
4. Check interval: 2 minutes.
5. Label: authelia redis session store.
6. Click Save.

If Redis is not exposed externally, expose a read-only sentinel endpoint or use a sidecar exporter that forwards a TCP health check through your Ingress.

Why Redis monitoring is critical: Authelia's health endpoint returns OK even when Redis is degraded if the connection pool has not yet timed out. The window between Redis going down and Authelia's health check failing can be several minutes — during which every authenticated user gets silently logged out.

Step 6: Monitor Upstream Identity Provider Connectivity

If Authelia is configured to delegate authentication to an external LDAP server or OIDC provider, the availability of those upstream services determines whether logins succeed:

# Check LDAP connectivity from Authelia pod
kubectl exec -n authelia deployment/authelia -- \
  ldapsearch -H ldap://ldap.example.com:389 -x -b "" -s base

# Check OIDC discovery endpoint
curl https://identity.example.com/.well-known/openid-configuration

In Vigilmon, add monitors for each upstream:

1. Add Monitor → HTTP.
2. URL: https://identity.example.com/.well-known/openid-configuration (for OIDC).
3. Check interval: 5 minutes.
4. Expected status: 200.
5. Label: authelia oidc provider discovery.
6. Click Save.

For LDAP, add a TCP monitor on port 389 (LDAP) or 636 (LDAPS) to detect connectivity loss.

Step 7: Monitor SSL Certificates

Authelia handles authentication for every protected service in your stack. A certificate expiry on the Authelia domain means every application shows a TLS error and nobody can log in:

# Check the Authelia domain certificate
openssl s_client -connect auth.example.com:443 2>/dev/null | \
  openssl x509 -noout -dates

# Check the OIDC provider certificate
openssl s_client -connect identity.example.com:443 2>/dev/null | \
  openssl x509 -noout -dates

In Vigilmon:

1. Add Monitor → SSL Certificate.
2. Domain: auth.example.com.
3. Alert when expiry is within: 30 days.
4. Alert again: 14 days, 7 days, 3 days, 1 day.
5. Click Save.

Repeat for your OIDC provider domain and any other HTTPS endpoints in the Authelia trust chain.

Step 8: Configure Alerting and Runbook

In Vigilmon under Settings → Notifications, configure your alert channels:

| Monitor | Trigger | Immediate Action | |---|---|---| | Health endpoint | Non-200 or OK keyword missing | kubectl get pods -n authelia → check restarts; kubectl logs -n authelia deployment/authelia --tail=30 | | Login portal | Non-200 or Authelia keyword missing | Check Ingress rules; kubectl describe ingress -n authelia; check middleware configuration | | Redis TCP | Connection refused | kubectl get pods -n authelia -l app=redis; check Redis memory usage and eviction policy | | OIDC provider | Non-200 on discovery endpoint | Check upstream OIDC provider status page; verify DNS resolution from cluster | | SSL certificate | < 30 days to expiry | Check cert-manager CertificateRequest status; kubectl get certificates -n authelia |

Escalation policy: Route Authelia alerts to an out-of-band channel (SMS, phone call) that does not require authentication to receive. If Authelia is down and your alert delivery channel is Slack behind Authelia SSO, you will not receive the alert about Authelia being down.

Common Authelia Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | Authelia pod OOM killed after traffic spike | Health endpoint goes down; alert within 1 min | | Redis evicts all keys under memory pressure | Health endpoint stays green; sessions expire; portal monitor catches login failures | | cert-manager fails to renew auth.example.com TLS cert | SSL monitor catches 30 days before browsers show errors | | LDAP server reboots during maintenance window | Health endpoint stays green; LDAP TCP monitor catches connectivity loss | | Helm upgrade deploys a bad Authelia config | Pod fails to start; health endpoint returns connection refused; alert within 1 min | | Ingress controller update changes forward-auth annotation format | Health endpoint stays green; portal monitor catches 502 on login page | | OIDC provider rotates signing keys without notice | Login attempts fail with signature errors; OIDC discovery monitor catches endpoint failures | | Redis auth password rotated without updating Authelia config | Authelia logs Redis auth failures; health endpoint degrades; TCP check catches Redis itself is fine |

Authelia is the single gateway between your users and every application in your stack. When it fails, nothing works — and because it's the authentication layer, users often don't get a meaningful error message, just an unexplained 401. Vigilmon closes this blind spot with independent external checks on Authelia's health endpoint, its Redis session backend, its upstream identity providers, and the TLS certificates that protect every authentication handshake. You get notified the moment any part of the authentication chain degrades, with enough diagnostic context to fix it before your users file a support ticket.

Start monitoring Authelia in under 5 minutes — register free at vigilmon.online.