Monitoring Kener with Vigilmon: Status Page Web UI, Health API, Monitor Status Feed & SSL Certificate Alerts

Your self-hosted Kener status page is the one tool you rely on to tell users when your services are down. If Kener itself goes offline — its Next.js server crashes, its polling engine stalls, or the HTTPS certificate for your public status domain expires — your users have no way of knowing you're aware of the incident, and you lose the communication channel exactly when you need it most. Vigilmon gives you external monitoring over every critical layer of a Kener deployment: the web UI, the health API, the monitor status feed, SSL certificate expiry, and Kener's own polling engine health.

What You'll Build

• An HTTP monitor on Kener's /api/health endpoint to confirm the server and API layer are up
• An HTTP monitor on the Kener web UI (port 3000) to confirm the Next.js frontend is serving
• An HTTP monitor on /api/status to confirm Kener's monitoring engine is running and checking services
• An SSL certificate monitor for your public Kener status page domain
• A heartbeat monitor to detect when Kener's polling engine has stalled

Prerequisites

• Kener running on your server (typically port 3000 — node server.js or Docker)
• A domain or IP:port accessible from the internet
• A free account at vigilmon.online

Step 1: Check the Kener Health API

Kener exposes a /api/health endpoint that returns a simple JSON response confirming the Next.js API layer and configuration are loaded:

curl http://kener.yourdomain.com:3000/api/health
# {"status":"ok"}

A 200 response with {"status":"ok"} confirms that the Node.js process is running, the Next.js server has initialized, and the Kener API routes are responding. A connection refused or non-200 response means the server has crashed or failed to start.

Step 2: Create the Health API Monitor in Vigilmon

1. Log in to Vigilmon → Add Monitor → HTTP.
2. URL: https://kener.yourdomain.com/api/health
3. Check interval: 60 seconds.
4. Response timeout: 10 seconds.
5. Expected status: 200.
6. Keyword: "status":"ok" (matches the JSON response body).
7. Label: Kener Health API
8. Click Save.

This monitor catches:

• Node.js process crashes or out-of-memory kills
• Next.js server startup failures due to misconfigured YAML or missing environment variables
• SQLite/Postgres database connection failures that prevent the API from initializing
• Port conflicts or permission errors that stop Kener from binding to port 3000

Step 3: Monitor the Kener Web UI

The health API doesn't exercise the full Next.js frontend rendering stack. A separate check on the root path confirms the status page itself is being served to end users:

curl -I http://kener.yourdomain.com:3000/
# HTTP/1.1 200 OK

1. Add Monitor → HTTP.
2. URL: https://kener.yourdomain.com/
3. Expected status: 200.
4. Keyword: Kener (present in the HTML page title and metadata of the default Kener UI).
5. Check interval: 120 seconds.
6. Label: Kener Web UI
7. Click Save.

If the health API passes but the web UI fails, the problem is in Next.js page rendering rather than the API layer — useful for catching theme or React hydration failures that leave the API responsive but the public page broken.

Step 4: Monitor the Kener Monitor Status Feed

Kener's /api/status endpoint returns the current health state of all configured monitors — each with its UP, DOWN, or DEGRADED status and a last_checked timestamp. Monitoring this endpoint from Vigilmon confirms that Kener's polling engine is actively checking services:

curl http://kener.yourdomain.com:3000/api/status
# {"monitors":[{"id":"website","status":"UP","last_checked":"2026-07-13T10:00:00Z",...},...]}

1. Add Monitor → HTTP.
2. URL: https://kener.yourdomain.com/api/status
3. Expected status: 200.
4. Keyword: monitors (confirms the response contains the monitor array).
5. Check interval: 120 seconds.
6. Label: Kener Monitor Status Feed
7. Click Save.

This distinguishes between "Kener is running" and "Kener is actually checking services." The API can return 200 while the polling scheduler has silently stalled — this monitor catches the degraded state where Kener appears healthy but has stopped doing its job.

Step 5: Monitor Your SSL Certificate

Kener status pages are typically served behind nginx or Caddy with a Let's Encrypt certificate. If the certificate on your public Kener domain expires, users visiting the status page see a browser TLS error instead of your incident updates — your status communication tool becomes unavailable precisely when you need to communicate a status:

1. Add Monitor → SSL Certificate.
2. Domain: kener.yourdomain.com
3. Alert when expiry is within: 30 days.
4. Alert again: 14 days, 7 days, 3 days.
5. Label: Kener SSL Certificate

The 30-day threshold gives you ample time to debug certbot or Caddy ACME renewal failures. A Let's Encrypt certificate that auto-renews every 60 days can fail silently if DNS changes break the HTTP-01 challenge — catching this before expiry is critical for a public-facing status page.

Step 6: Heartbeat Monitor for Kener's Polling Engine

Kener polls its configured monitors on a schedule. If the scheduler stalls — due to a Node.js event loop blockage, a database write lock, or a memory pressure issue — Kener continues to serve the UI and API with the last-known status, but stops updating. The last_checked timestamps in /api/status become increasingly stale without any error being surfaced.

Set up a server-side script that pings Vigilmon only when Kener's monitors are being checked on time:

#!/bin/bash
# /etc/cron.d/kener-polling-heartbeat — runs every 5 minutes

KENER_API="http://localhost:3000/api/status"
# Maximum acceptable age for last_checked (in seconds): 2x your fastest poll interval
MAX_AGE_SECONDS=600

STATUS=$(curl -fsS "$KENER_API")
if [ $? -ne 0 ]; then
  echo "Kener API unreachable — skipping heartbeat"
  exit 1
fi

# Check if any monitor's last_checked is within the acceptable window
RECENT=$(echo "$STATUS" | python3 -c "
import sys, json, datetime, urllib.parse
data = json.load(sys.stdin)
now = datetime.datetime.utcnow()
monitors = data.get('monitors', [])
for m in monitors:
    lc = m.get('last_checked', '')
    if lc:
        ts = datetime.datetime.strptime(lc, '%Y-%m-%dT%H:%M:%SZ')
        if (now - ts).total_seconds() < $MAX_AGE_SECONDS:
            print('ok')
            sys.exit(0)
print('stale')
")

if [ "$RECENT" = "ok" ]; then
  curl -fsS -X POST https://vigilmon.online/api/heartbeat/YOUR-HEARTBEAT-ID
fi

In Vigilmon:

1. Add Monitor → Heartbeat.
2. Expected interval: 5 minutes.
3. Grace period: 15 minutes.
4. Label: Kener Polling Engine Health

When Kener's polling scheduler stalls, the heartbeat stops firing and Vigilmon alerts you — before your users notice that the last incident timestamp on the status page is hours old.

Common Kener Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | Node.js process crash or OOM-kill | Health API returns connection refused; alert fires within 60 s | | Next.js build or React render failure | Web UI check fails; Health API may still return 200 | | Polling scheduler stalled (stale last_checked) | Polling engine heartbeat stops; alert fires after grace period | | SQLite database locked or corrupted | Health API returns non-200 or error keyword | | nginx/Caddy reverse proxy misconfiguration | Web UI and API checks fail; server may still be running on port 3000 | | Let's Encrypt certificate expires on status domain | SSL monitor alerts at 30 days before expiry | | YAML config parse error on restart | Health API returns 500; process fails to initialize API routes | | DNS change breaks public status page access | All external monitors fire simultaneously |

Kener is designed to be your incident communication layer — but it can't tell users about its own downtime. External monitoring from Vigilmon closes that gap: if Kener's process crashes, its polling engine stalls, or its SSL certificate lapses, you'll know before your users do.

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