Monitoring Clerk with Vigilmon: Auth API Uptime, Webhook Delivery, SSL Certificates & JWT Endpoint Checks

Clerk is the authentication layer for thousands of SaaS applications — handling sign-in, sign-up, session management, JWTs, and multi-factor authentication in production. When Clerk's API becomes unavailable, every user-facing login flow breaks immediately. Your sign-in pages return errors, protected routes reject valid sessions, and user onboarding grinds to a halt. Vigilmon gives you external visibility into Clerk's reachability from your region so you know about degradation before your users or Sentry does: API endpoint availability, webhook delivery health, SSL certificate expiry, and JWT verification uptime.

What You'll Build

A monitor on Clerk's public API status endpoint
An HTTPS check on your Frontend API domain (the .clerk.accounts.dev or custom domain Clerk provisions for your app)
SSL certificate monitoring for your Clerk domain
Webhook delivery endpoint monitoring
A JWT verification endpoint check
Alerting that separates Clerk-platform outages from your own app configuration issues

Prerequisites

A Clerk application with a publishable key and at least one sign-in method configured
Your Clerk Frontend API URL (shown in the Clerk dashboard under API Keys, e.g., https://your-app.clerk.accounts.dev or a custom domain)
A free account at vigilmon.online

Step 1: Check Clerk's Status API

Clerk maintains a status page and a machine-readable status endpoint. Verify it is accessible from your monitoring region:

curl https://status.clerk.com/api/v2/status.json

A healthy response includes:

{
  "status": {
    "indicator": "none",
    "description": "All Systems Operational"
  }
}

This endpoint reflects Clerk's aggregate infrastructure status. Add it as a baseline monitor:

Log in to Vigilmon → Add Monitor → HTTP.
URL: https://status.clerk.com/api/v2/status.json.
Check interval: 60 seconds.
Expected status: 200.
Keyword: none (matches indicator when all systems are operational).
Label: Clerk Platform Status.
Click Save.

Incident context: When this monitor fires, Clerk is experiencing a platform-level incident — check the status page for affected components and ETAs before spending time debugging your own code.

Step 2: Monitor Your Clerk Frontend API Domain

Every Clerk application has a dedicated Frontend API URL. This is the domain your SDKs hit for authentication requests — JWKS fetching, session token validation, and sign-in flows all go through it. Monitor it directly:

curl https://your-app.clerk.accounts.dev/v1/health

A healthy Clerk instance returns 200 with a JSON body. Add the monitor:

Add Monitor → HTTP.
URL: https://your-app.clerk.accounts.dev/v1/health (replace with your actual Frontend API URL).
Check interval: 60 seconds.
Response timeout: 10 seconds.
Expected status: 200.
Label: Clerk Frontend API.
Click Save.

Why this matters: Clerk's global status may show green while a specific region or your provisioned instance is degraded. Your Frontend API monitor catches those narrower outages that the aggregate status endpoint misses.

Step 3: Monitor SSL Certificates

Clerk issues JWTs signed with certificates tied to your Frontend API domain. If that domain's SSL certificate expires — whether on Clerk's side or a custom domain you manage — browser SDK requests will immediately fail with certificate errors:

curl -v https://your-app.clerk.accounts.dev 2>&1 | grep -i "expire"

Add SSL monitoring with early warnings:

Add Monitor → SSL Certificate.
Domain: your-app.clerk.accounts.dev (or your custom Clerk domain).
Alert when expiry is within: 30 days.
Alert again: 14 days, 7 days, 3 days, 1 day.
Click Save.

If you use a custom domain with Clerk, add a separate SSL monitor for that domain. Custom-domain SSL certificates are more likely to lapse because they often go through your own DNS provider and certificate automation rather than Clerk's managed infrastructure.

Step 4: Monitor Your Webhook Receiver Endpoint

Clerk sends webhooks for user lifecycle events — user.created, session.ended, email.created, and others. These drive downstream automation: syncing users to your database, sending welcome emails, provisioning workspaces. If your webhook receiver is down, these events queue and fail silently.

Monitor your webhook endpoint so you know it is reachable before Clerk tries to deliver to it:

Add Monitor → HTTP.
URL: https://your-app.com/api/webhooks/clerk (your webhook receiver URL).
Check interval: 5 minutes.
Expected status: 200 or 405 (a 405 Method Not Allowed on a GET proves the endpoint is up even if it only accepts POST).
Label: Clerk Webhook Receiver.
Click Save.

Svix integration: Clerk uses Svix for webhook delivery. Svix retries failed deliveries for up to 5 days, but you still want to know your endpoint is up so events are processed in real time rather than caught up from a retry backlog.

Step 5: Monitor the JWKS Endpoint

Clerk's JSON Web Key Set (JWKS) endpoint publishes the public keys your backend uses to verify JWTs. Your server fetches and caches these keys — but if the endpoint is unreachable when the cache expires, JWT verification will fail and your API will reject valid user sessions:

curl https://your-app.clerk.accounts.dev/.well-known/jwks.json

A healthy response is a JSON object with a keys array. Add a monitor:

Add Monitor → HTTP.
URL: https://your-app.clerk.accounts.dev/.well-known/jwks.json.
Check interval: 5 minutes.
Expected status: 200.
Keyword: keys (always present in a valid JWKS document).
Label: Clerk JWKS Endpoint.
Click Save.

This is particularly important for self-hosted backends that perform local JWT verification — any gap in JWKS availability directly impacts your API's ability to authenticate requests.

Step 6: Configure Alerting

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

| Monitor | Trigger | Action | |---|---|---| | Clerk Platform Status | indicator not none | Check status.clerk.com for incident details and ETA | | Clerk Frontend API | Non-200 or timeout | Verify DNS resolution; check Clerk dashboard for region alerts | | SSL Certificate | < 30 days to expiry | Renew or verify auto-renewal is working for your Clerk domain | | Webhook Receiver | Non-200/405 | Check your server deployment; inspect webhook delivery logs in Clerk dashboard | | JWKS Endpoint | Non-200 or keys missing | Backends may fail JWT verification; check Clerk status and clear JWT caches |

Alert sensitivity: Set all Clerk monitors to alert after 1 consecutive failure. A single authentication failure during a live session causes an immediate user-visible error — there is no soft degradation to average out.

Common Clerk Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | Clerk platform incident | Status API fires; indicator becomes minor, major, or critical | | Frontend API unreachable in your region | Frontend API monitor fires; platform status may stay green | | SSL certificate expires on custom domain | SSL monitor alerts at 30-day threshold | | Webhook receiver crashes after deploy | Webhook receiver monitor fires; Clerk queues undelivered events | | JWKS endpoint degraded; JWT cache expires | JWKS monitor fires; API requests begin returning 401 | | DNS misconfiguration after domain change | Frontend API and JWKS monitors fire simultaneously | | Rate limiting or DDoS mitigation active | Frontend API returns 429; check Clerk incident page |

Clerk abstracts away enormous authentication complexity — but that abstraction means an outage in Clerk's infrastructure propagates directly to every user login in your app. Vigilmon gives you external, region-accurate monitoring of every Clerk touchpoint: the platform status API, your provisioned Frontend API domain, SSL certificates, your webhook receiver, and the JWKS endpoint your backend depends on for JWT verification. Know about Clerk degradation in seconds so you can post a status update, queue a rollback, or open a support ticket before users start filing bugs.

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