tutorial

Monitoring Logto with Vigilmon: API Status, Admin Console, OIDC Discovery & SSL Alerts

How to monitor Logto open-source auth and identity platform with Vigilmon — /api/status health endpoint, admin console UI, OIDC discovery endpoint, and SSL certificate alerts.

Logto is the open-source authentication and identity platform that teams use to add sign-in, MFA, and user management to their applications. Because Logto sits at the authentication boundary, its availability is a hard dependency for every application that delegates sign-in to it: if Logto goes down, users cannot log in. If the OIDC discovery endpoint returns an error, OAuth2 and OIDC clients fail their initialization handshake. If the SSL certificate expires, every browser redirected to the login page gets a TLS error. Vigilmon gives you external visibility into Logto's API status endpoint, admin console, OIDC discovery endpoint, and SSL certificate so you can respond before users are locked out.

What You'll Build

  • An HTTP monitor on Logto's /api/status health endpoint
  • An HTTP monitor for admin console availability
  • An HTTP monitor for the OIDC discovery endpoint
  • SSL certificate monitoring for your Logto domain

Prerequisites

  • A running Logto instance with a public or network-reachable domain
  • HTTPS configured (e.g., https://auth.example.com)
  • A free account at vigilmon.online

Step 1: Verify Logto's API Status Endpoint

Logto exposes a dedicated health check at /api/status that confirms the core API is running:

curl https://auth.example.com/api/status

A healthy Logto instance returns HTTP 204 No Content — an empty body with a success status code. Some versions return HTTP 200 with a JSON body. Either response confirms the API server is up and the database connection is active.

# Check the HTTP status code specifically
curl -o /dev/null -w "%{http_code}" https://auth.example.com/api/status

This endpoint requires no authentication and is designed for health probes and load balancer checks.

Version note: Logto Cloud and recent self-hosted versions consistently return 204. If you're on an older version, confirm the expected status code before setting up the monitor.


Step 2: Create a Vigilmon HTTP Monitor for the API Status Endpoint

  1. Log in to VigilmonAdd Monitor → HTTP.
  2. URL: https://auth.example.com/api/status.
  3. Check interval: 60 seconds.
  4. Response timeout: 15 seconds.
  5. Expected status: 204 (or 200 if your version returns JSON).
  6. Label: Logto API Status.
  7. Click Save.

This monitor catches:

  • Logto API server crashes or container restarts
  • PostgreSQL database connectivity failures
  • Redis connectivity issues (Logto uses Redis for session management)
  • Application-level startup failures after upgrades

Step 3: Monitor the Admin Console UI

The Logto admin console is where you manage users, applications, connectors, and identity provider settings. It's served from a separate path (/console) and can fail independently of the API.

curl -I https://auth.example.com/console

A healthy Logto admin console returns HTTP 200 (or a redirect to the login page) with HTML containing Logto in the title.

  1. Add Monitor → HTTP.
  2. URL: https://auth.example.com/console.
  3. Check interval: 5 minutes.
  4. Expected status: 200.
  5. Keyword: Logto.
  6. Label: Logto Admin Console.
  7. Click Save.

When the admin console monitor fires but the API status is green, you have a frontend delivery issue — a broken static asset build or a misconfigured reverse proxy route. The authentication backend is working, but no one can manage it.


Step 4: Monitor the OIDC Discovery Endpoint

The OIDC discovery endpoint (/.well-known/openid-configuration) is one of the most critical routes in Logto. Every OIDC and OAuth2 client your applications use fetches this document at startup to discover Logto's authorization endpoint, token endpoint, JWKS URI, and supported scopes. If this endpoint returns an error or stale data, client initialization fails and users cannot log in even if Logto itself is running.

curl https://auth.example.com/oidc/.well-known/openid-configuration

A healthy response is HTTP 200 with a JSON document containing issuer, authorization_endpoint, token_endpoint, and jwks_uri.

  1. Add Monitor → HTTP.
  2. URL: https://auth.example.com/oidc/.well-known/openid-configuration.
  3. Check interval: 2 minutes.
  4. Expected status: 200.
  5. Keyword: authorization_endpoint.
  6. Label: Logto OIDC Discovery.
  7. Click Save.

Why this matters separately: The API status endpoint can return 204 while the OIDC discovery document fails if there's a routing misconfiguration, a broken OIDC middleware, or a malformed issuer configuration. Monitoring the discovery endpoint independently catches these subtle failures that the health check misses.


Step 5: Monitor SSL Certificates

Logto's SSL certificate covers every login redirect your users go through and every OAuth2 callback your applications receive. A certificate expiry is especially disruptive because:

  • All user login attempts fail with TLS errors
  • OIDC client libraries fail their discovery document fetch at startup
  • Every application relying on Logto for authentication goes offline simultaneously
  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.

If you're using Let's Encrypt, a 30-day alert almost always means automatic renewal has failed — check your ACME client logs before the deadline.


Step 6: Configure Alerting

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

| Monitor | Trigger | Action | |---|---|---| | /api/status | Non-204/200 | Check Logto container; verify PostgreSQL and Redis connectivity | | Admin console | Non-200 or keyword missing | Check frontend build; review reverse proxy config for /console | | OIDC discovery | Non-200 or keyword missing | Check OIDC middleware; verify issuer URL configuration | | SSL certificate | < 30 days to expiry | Renew certificate; check ACME client or TLS termination config |

Alert after: 2 consecutive failures for HTTP monitors. 1 failure for SSL monitors.


Common Logto Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | Logto server crash | API status unreachable; alert within 60 s | | PostgreSQL goes down | API status non-204; all logins and user management fail | | Redis goes down | Sessions lost; existing sessions may fail; health check may still pass | | OIDC middleware misconfiguration | Discovery endpoint fails; all client initializations break | | Admin console deploy failure | Admin UI monitor fires; API and OIDC stay green | | SSL certificate expires | SSL monitor alerts at 30 days; all browser logins blocked | | Issuer URL mismatch after upgrade | OIDC discovery returns 200 but clients reject the issuer claim | | DNS misconfiguration | All HTTP and SSL monitors fire simultaneously |


Logto is the authentication gateway for every application in your stack that delegates sign-in to it. Vigilmon watches the API status endpoint, admin console, OIDC discovery document, and SSL certificate so you know the moment Logto has a problem, before users report they cannot log in to any of your services.

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

Monitor your app with Vigilmon

Free plan — 5 monitors, no credit card required. Up and running in 60 seconds.

Start free →