tutorial

Gotify Monitoring with Vigilmon: Web UI, Health Endpoint, WebSocket Service & Notification Delivery Checks

Monitor your self-hosted Gotify push notification server with Vigilmon — track web UI availability, the /health endpoint, WebSocket push service, message delivery API, SSL certificates, and notification delivery heartbeat.

You built a script that sends push notifications via your self-hosted Gotify server — deployment completions, backup confirmations, cron job results. Everything was working until the Gotify container restarted and nobody noticed. The health check script kept running, but notifications weren't delivering. The Android app showed the old cached state and nobody got a critical alert about a failed database backup.

Gotify is a self-hosted push notification server that lets your applications and scripts send push notifications to Android devices, web apps, and any HTTP client. It's lightweight, simple, and trusted for personal and homelab automations. But when Gotify goes down, the silence is the failure — your scripts continue running and return 200s on message sends, but nobody receives anything. Vigilmon gives you the external monitoring to catch Gotify failures the moment they happen.

This tutorial walks through monitoring Gotify end-to-end with Vigilmon.

What You'll Build

  • A Vigilmon HTTP monitor on the Gotify web UI
  • A health endpoint check
  • A message delivery API check
  • A Vigilmon heartbeat for notification delivery confirmation
  • SSL certificate expiry alerts

Prerequisites

  • A running Gotify instance (v2.4.x or later recommended)
  • A free account at vigilmon.online
  • A Gotify application token (for the delivery API check)

Step 1: Monitor the Gotify Web UI

The Gotify web interface serves as the admin dashboard and message viewer. A 200 response confirms that the Go process and its embedded web server are running.

Test it:

curl -I https://gotify.yourdomain.com/

You should see 200 OK with a Content-Type: text/html response.

Set up the Vigilmon monitor:

  1. Log in to Vigilmon and click New Monitor → HTTP.
  2. Set URL to https://gotify.yourdomain.com/.
  3. Set Check interval to 60 seconds.
  4. Set Expected status code to 200.
  5. Under Advanced → Keyword check, add keyword present: Gotify.
  6. Save the monitor.

Step 2: Monitor the Health Endpoint

Gotify exposes a /health endpoint that returns service health status. This is the canonical liveness check and the most reliable signal that the Gotify service is operational.

Test it:

curl https://gotify.yourdomain.com/health

Healthy response:

{
  "health": "green",
  "database": "green"
}

A "health": "green" response confirms that Gotify's Go process and its SQLite (or MySQL/PostgreSQL) database are both healthy.

Set up the monitor:

  1. Click New Monitor → HTTP in Vigilmon.
  2. Set URL to https://gotify.yourdomain.com/health.
  3. Set Expected status code to 200.
  4. Under Advanced → Keyword check, add:
    • Keyword present: "green"
    • Keyword absent: "red"
  5. Save.

Step 3: Notification Delivery Heartbeat

The most important thing Vigilmon can monitor for a push notification server is whether notifications are actually being delivered. Gotify passing /health checks means nothing if messages aren't reaching clients.

Set this up as a round-trip test: a cron job on your server sends a Gotify notification every 5 minutes, and Vigilmon monitors a heartbeat endpoint that gets pinged when the notification is received. For a simpler version, you can monitor the message send API directly.

Step 3a: Create the Vigilmon heartbeat monitor.

  1. Click New Monitor → Heartbeat in Vigilmon.
  2. Set Name to Gotify Notification Delivery.
  3. Set Expected interval to 5 minutes.
  4. Set Grace period to 2 minutes.
  5. Save and copy the heartbeat ping URL (e.g., https://vigilmon.online/heartbeat/abc123).

Step 3b: Schedule a periodic self-test notification.

Add a cron job that sends a message via Gotify and immediately pings Vigilmon if successful:

# /etc/cron.d/gotify-healthcheck
*/5 * * * * root curl -s -X POST "https://gotify.yourdomain.com/message?token=YOUR_APP_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"message": "Heartbeat OK", "priority": 0, "title": "Vigilmon Heartbeat"}' \
  && curl -s https://vigilmon.online/heartbeat/abc123

Replace YOUR_APP_TOKEN with a dedicated Gotify application token created for monitoring purposes. If the curl to Gotify fails (non-zero exit), the && short-circuits and Vigilmon's heartbeat is never pinged — triggering an alert.


Step 4: Monitor the Message Send API

Beyond the heartbeat, you can directly monitor whether Gotify's message API accepts requests. This catches cases where the API is broken but the health endpoint still returns green.

Test it:

curl https://gotify.yourdomain.com/message?token=YOUR_APP_TOKEN \
  -H "Content-Type: application/json" \
  -d '{"message": "test", "priority": 0, "title": "Monitor Test"}'

Healthy response:

{
  "id": 42,
  "appid": 1,
  "message": "test",
  "title": "Monitor Test",
  "priority": 0
}

For external monitoring, set up a dedicated read-only check. Since Gotify requires authentication to send messages, the heartbeat approach in Step 3 is the recommended external delivery check.


Step 5: SSL Certificate Monitoring

Push notification clients connect to Gotify over HTTPS. An expired certificate causes all app clients to stop receiving notifications immediately — the Android app will show connection errors and no notifications will be delivered. Vigilmon automatically monitors SSL certificate validity on all HTTPS monitors.

  1. Open your Gotify web UI monitor in Vigilmon.
  2. Under Advanced → SSL, ensure Alert before expiry is enabled (default: 14 days).
  3. Save.

Step 6: Alert Channels

Go to Notifications → New Channel in Vigilmon and configure:

  • Email — for your instance admin (since Gotify itself may be down, don't rely solely on Gotify for alerts)
  • Webhook — for Slack or Discord

The critical lesson with Gotify monitoring: do not route Vigilmon alerts exclusively through Gotify. If Gotify is down, that alert delivery path is broken. Always configure at least one independent alert channel.

A heartbeat alert looks like:

🔴 DOWN: Gotify Notification Delivery (Heartbeat)
No ping received in the last 7 minutes (expected every 5)
Triggered: 2026-03-01 16:45 UTC

What You've Built

| Scenario | How Vigilmon catches it | |---|---| | Gotify process crash | HTTP monitor and /health both fail | | Database unavailable | /health returns "database": "red" | | Message API broken | Heartbeat cron job fails; Vigilmon not pinged | | WebSocket push service down | Client apps disconnect; heartbeat catches delivery failure | | SSL certificate expired | HTTPS monitor reports TLS error | | DNS misconfiguration | HTTP monitor detects resolution failure | | Container/VM restart | HTTP monitors detect downtime immediately |


Gotify's value is the quiet reliability of knowing your automations are reaching you. When it fails silently, the alerts you depend on for backups, deployments, and system health simply never arrive. Vigilmon's external monitoring — especially the delivery heartbeat — closes that blind spot and ensures Gotify's silence is only ever intentional.

Start monitoring your Gotify 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 →