tutorial

SuperTokens Monitoring with Vigilmon: Uptime, Core API & Dashboard Health Checks for Self-Hosted Auth

Monitor your self-hosted SuperTokens instance with Vigilmon — use the /hello health endpoint, verify core API availability, check the dashboard UI, and get SSL certificate alerts so authentication never becomes your single point of failure.

At 2am, your users start getting logged out. Your app's authentication calls are timing out. The SuperTokens core is down and every API request that requires a valid session is failing. By the time someone on your team notices, your app has been throwing auth errors for 45 minutes and users are filing password reset requests for a problem that has nothing to do with their passwords.

SuperTokens is an open-source authentication and session management platform that teams self-host to avoid vendor lock-in on their auth stack. When SuperTokens goes down, every login, session refresh, and token validation call fails — which typically means your entire application stops working for authenticated users.

Vigilmon gives you the external monitoring to catch SuperTokens failures at the health endpoint level, before they cascade into application-wide outages.

What You'll Build

  • A Vigilmon HTTP monitor on SuperTokens' built-in /hello health endpoint
  • A core API availability monitor
  • A dashboard UI check
  • SSL certificate expiry alerts
  • Alert channels with fast response times for auth infrastructure

Prerequisites

  • A running SuperTokens Core instance (v9.x recommended)
  • A free account at vigilmon.online

Step 1: Monitor the SuperTokens /hello Health Endpoint

SuperTokens Core ships with a built-in health check endpoint at /hello that requires no authentication and returns a simple alive confirmation.

Test it:

curl https://auth.example.com:3567/hello

Expected response:

Hello

With HTTP status 200 OK.

The /hello endpoint is intentionally minimal. A 200 response confirms that the SuperTokens Core Java process is running, the HTTP server is accepting connections, and the basic request pipeline is healthy. If the process crashes, the database becomes unreachable, or the JVM runs out of memory, this endpoint stops responding.

Set up the Vigilmon monitor:

  1. Log in to Vigilmon and click New Monitor → HTTP.
  2. Set URL to https://auth.example.com:3567/hello (adjust port if you've changed the default 3567).
  3. Set Check interval to 30 seconds — auth infrastructure warrants faster polling.
  4. Set Expected status code to 200.
  5. Under Advanced → Keyword check:
    • Keyword present: Hello
  6. Save the monitor.

Vigilmon now polls your SuperTokens Core health endpoint every 30 seconds. For auth infrastructure, faster detection means faster recovery.

Step 2: Monitor Core API Availability

Beyond the health endpoint, SuperTokens' core API handles actual authentication operations. You can verify the API is functional without triggering real auth flows by hitting the recipe list or version endpoint.

Test the API version endpoint:

curl https://auth.example.com:3567/apiversion

Expected response:

{
  "versions": ["2.21", "3.0"]
}

Add a core API monitor:

  1. Click New Monitor → HTTP in Vigilmon.
  2. Set URL to https://auth.example.com:3567/apiversion.
  3. Set Expected status code to 200.
  4. Under Advanced → Keyword check:
    • Keyword present: "versions"
  5. Set Check interval to 60 seconds.
  6. Save.

This endpoint exercises the API routing layer and confirms the core is advertising its supported API versions — a prerequisite for your backend SDK to communicate with it correctly. A version mismatch or routing failure here can cause subtle auth SDK failures that the /hello check wouldn't catch.

Step 3: Monitor the SuperTokens Dashboard UI

SuperTokens includes a built-in user management dashboard that your team uses to inspect sessions, manage users, and debug authentication issues. The dashboard is a separate HTTP frontend served from the core.

Add a dashboard monitor:

  1. Click New Monitor → HTTP in Vigilmon.
  2. Set URL to https://auth.example.com:3567/auth/dashboard (or your configured dashboard path).
  3. Set Expected status code to 200.
  4. Under Advanced → Keyword check:
    • Keyword present: SuperTokens
    • Keyword absent: 502 Bad Gateway, 404 Not Found
  5. Set Check interval to 120 seconds.
  6. Save.

Dashboard failures are lower severity than core failures, but they matter during incidents — if you can't access the dashboard when users are locked out, debugging takes longer.

Step 4: SSL Certificate Monitoring

If you expose SuperTokens Core over HTTPS (recommended, especially when it's accessible outside localhost), a lapsed certificate will break every backend SDK call and every auth operation in your application.

Vigilmon checks the TLS certificate automatically on every HTTPS monitor. Configure expiry alerts:

  1. Open your /hello monitor in Vigilmon.
  2. Click Settings → SSL Certificate.
  3. Set Alert when certificate expires in less than to 21 days.
  4. Save.

Auth infrastructure certificate expiry is a high-severity event. A 21-day warning — longer than the standard 14-day threshold — gives you three weeks to renew before any client SDKs start refusing connections.

If SuperTokens Core runs on localhost and only your backend communicates with it over an internal network, you may not need HTTPS monitoring on the core itself. In that case, focus your SSL monitoring on the domain your users connect to (your application's public domain).

Step 5: Alert Channels

Go to Notifications → New Channel in Vigilmon and configure:

  • Email — immediate alerts to your backend or infrastructure team
  • Webhook — post to PagerDuty, OpsGenie, Slack, or Teams

For auth infrastructure, route alerts to your highest-priority on-call channel. When SuperTokens goes down, your application stops working for authenticated users — this is a P1.

A PagerDuty-style alert looks like:

🔴 DOWN: auth.example.com:3567/hello
Status: No response (connection timeout)
Region: US-East
Triggered: 2026-05-14 02:17 UTC
Duration: 2m 30s (escalating)

When SuperTokens recovers:

✅ RECOVERED: auth.example.com:3567/hello
Downtime: 4 minutes 12 seconds

Set a minimum downtime threshold of 2 minutes before alerting to avoid false positives from transient network hiccups — but keep it short enough that a real auth outage triggers your on-call rotation before users notice.

Step 6: Status Page

Go to Status Pages → New Status Page in Vigilmon. Add all SuperTokens monitors (health, API version, dashboard) and optionally your main application monitors.

For auth infrastructure, a status page is most useful internally — share it with your engineering team so everyone can see the state of auth services at a glance during an incident:

<a href="https://vigilmon.online/status/<your-slug>">
  <img src="https://vigilmon.online/badge/<monitor-slug>" alt="Auth Service Status" />
</a>

What You've Built

| Scenario | How Vigilmon catches it | |---|---| | SuperTokens Core process crash (JVM/OOM) | /hello monitor detects no response | | Database (MySQL/PostgreSQL) unreachable | Core returns error on /hello or /apiversion | | Reverse proxy or network routing failure | Both monitors detect connection failure | | API version routing broken | /apiversion monitor returns non-200 | | Dashboard UI inaccessible | Dashboard monitor detects 404 or 502 | | SSL certificate expired | Vigilmon TLS check fires 21 days before expiry | | Port blocked by firewall rule change | All monitors detect connection refused | | Server reboot without auto-restart | Process down; /hello monitor fires immediately |

Authentication is the front door to your application. When it goes down, nothing else matters. SuperTokens won't send you a page when it crashes — Vigilmon will.

Start monitoring your SuperTokens instance today — 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 →
← Back to all articles