tutorial

Monitoring Bark Self-Hosted Push Notification Server with Vigilmon

Bark is a self-hosted iOS push notification relay using Apple's APNs — but if your server is unreachable or APNs connectivity breaks, your iPhone notifications silently stop. Here's how to monitor every layer of Bark with Vigilmon.

Bark is an open-source Go server that lets you send push notifications to your iPhone or iPad from any application, script, or automation — without relying on a third-party notification service. It relays your messages to Apple's Push Notification service (APNs) and delivers them to the Bark iOS app. It's elegant and lightweight, but it introduces a monitoring gap: if the Bark server goes down, your notifications stop silently. You won't know your home automation alerts, server down-alerts, or price alerts are queuing up nowhere until you notice you haven't heard from them. Vigilmon closes that loop, monitoring Bark's HTTP server, APNs connectivity, TLS certificates, and database health.

What You'll Set Up

  • Bark HTTP server availability (port 8080)
  • Push notification delivery endpoint response time monitoring (/push/:deviceKey)
  • TLS/HTTPS certificate expiry alerts
  • Database (BBolt/SQLite) connectivity via API health check
  • APNs upstream connectivity via delivery success tracking
  • Rate limiting middleware liveness
  • Cron heartbeat for end-to-end notification delivery verification

Prerequisites

  • Bark server running on port 8080 (or your configured port)
  • TLS configured (strongly recommended — APNs requires HTTPS for production use)
  • At least one device key registered from the Bark iOS app
  • A free Vigilmon account

Step 1: Monitor Bark HTTP Server Availability

Bark's HTTP server is the single entry point for all notification requests. If it's down, nothing works.

  1. Log in to vigilmon.online and click Add Monitor.
  2. Set Type to HTTP / HTTPS.
  3. Enter your Bark URL: https://bark.yourdomain.com or http://your-server-ip:8080.
  4. Set Check interval to 1 minute.
  5. Set Expected HTTP status to 200.
  6. Click Save.

Bark's root endpoint (/) returns a simple 200 OK with a welcome message. Enable Keyword match and enter Bark to confirm the Bark process is responding (not a different service on the same port).

Step 2: Monitor the Push Delivery Endpoint

The /push/:deviceKey endpoint is where notifications are sent. Monitor its response time to catch performance degradation before it affects delivery latency:

  1. Click Add Monitor → HTTP / HTTPS.

  2. URL: https://bark.yourdomain.com/ping (Bark exposes a /ping health endpoint that exercises the core delivery path without sending a real notification).

    If Bark doesn't expose /ping in your version, use: https://bark.yourdomain.com/healthcheck

  3. Check interval: 2 minutes.

  4. Expected HTTP status: 200.

  5. Enable Response time threshold: alert at 3000 ms.

  6. Click Save.

Bark's healthy response time is typically under 500 ms for the delivery path (including APNs round-trip). A threshold of 3 seconds catches APNs connectivity degradation before full failures begin.

Step 3: TLS Certificate Expiry Alerts

APNs requires your Bark server to serve HTTPS in production environments. An expired TLS certificate breaks the Bark iOS app's connection to your server, silently stopping all notifications.

  1. Open the HTTP monitor for your Bark domain.
  2. Enable Monitor SSL certificate.
  3. Set Alert when certificate expires in less than 21 days.
  4. Click Save.

Also monitor your APNs authentication key or APNs certificate validity. APNs authentication keys (.p8 files) do not expire — but APNs certificates (.p12 files) expire annually and must be renewed through the Apple Developer Portal. If you use .p12 certificates:

  • Set a calendar reminder at 30 days before expiry, OR
  • Add a Vigilmon cron heartbeat that pings after your manual APNs certificate renewal process (Step 7).

Step 4: Monitor Database Connectivity

Bark uses BBolt (embedded key-value store) or SQLite to persist device registrations and notification history. A corrupted or locked database causes registration failures and notification drops.

Bark's API response includes database-backed data — use the device registration check endpoint to verify database reads are functioning:

  1. Click Add Monitor → HTTP / HTTPS.

  2. URL: https://bark.yourdomain.com/info (if available) or your registered device key endpoint: https://bark.yourdomain.com/YOUR_DEVICE_KEY/test?title=Vigilmon+check&body=health

    Note: Sending a test notification as a health check has the side effect of delivering a notification to your device. For a non-intrusive check, use the Bark ping or server info endpoint if your version supports it.

  3. Check interval: 5 minutes.

  4. Expected HTTP status: 200.

  5. Enable Keyword match: "code":200 — Bark wraps successful responses in a JSON envelope with "code": 200.

  6. Click Save.

Step 5: APNs Connectivity Monitoring via Delivery Endpoint

APNs is Apple's upstream push relay — Bark has no control over it, but your server must maintain a persistent connection to APNs to deliver notifications. APNs connectivity failures show up as delivery errors in Bark's logs and as slow or erroring push delivery endpoints.

Monitor APNs connectivity indirectly via the push delivery endpoint response time (set up in Step 2) and response body:

  • Enable Keyword match on the delivery endpoint for "code":200 — an APNs connectivity failure returns a non-200 code in Bark's JSON envelope even if the HTTP status is 200.
  • Set Response time threshold at 5000 ms — APNs failures cause Bark to wait for a timeout before returning.

For direct APNs connectivity testing, use Vigilmon's TCP port monitor:

  1. Click Add Monitor → TCP Port.
  2. Host: api.push.apple.com.
  3. Port: 443.
  4. Check interval: 5 minutes.
  5. Timeout: 10 seconds.
  6. Click Save.

This checks that your server can reach Apple's APNs endpoint — a firewall rule blocking outbound port 443 to Apple's IP ranges will silently kill all notifications.

Step 6: Monitor Rate Limiting Middleware

Bark includes rate limiting to prevent abuse of the push endpoint. If the rate limiter middleware becomes misconfigured (too aggressive), legitimate notification requests are rejected with 429 errors.

Add a Vigilmon alert for unexpected 429 responses:

  1. Open the push delivery monitor from Step 2.
  2. Set Alert on unexpected HTTP status — Vigilmon alerts if the response is not your expected 200.
  3. Confirm Expected HTTP status is 200.
  4. Click Save.

A sudden stream of 429 Too Many Requests alerts from Vigilmon's monitoring probes indicates the rate limiter is too aggressive for your server's configured limits — adjust Bark's RateLimit setting accordingly.

Step 7: End-to-End Delivery Verification via Cron Heartbeat

HTTP 200 from Bark's endpoint only proves the HTTP layer is alive. It doesn't prove notifications are reaching the Bark iOS app. Use Vigilmon's cron heartbeat for end-to-end verification:

  1. In Vigilmon, click Add Monitor → Cron Heartbeat.
  2. Set expected ping interval to 60 minutes.
  3. Copy the heartbeat URL.
  4. Create a script or automation that sends a test notification via Bark and, after confirming delivery (200 from Bark), pings Vigilmon:
#!/bin/bash
BARK_SERVER="https://bark.yourdomain.com"
DEVICE_KEY="YOUR_DEVICE_KEY"
HEARTBEAT_URL="https://vigilmon.online/heartbeat/YOUR_HEARTBEAT_ID"

RESPONSE=$(curl -s -o /dev/null -w "%{http_code}" \
  "$BARK_SERVER/$DEVICE_KEY/Vigilmon+Check/Hourly+health+check")

if [ "$RESPONSE" = "200" ]; then
    curl -s "$HEARTBEAT_URL"
fi

Run this script via cron:

0 * * * * /usr/local/bin/bark-heartbeat.sh

If the end-to-end delivery breaks — because APNs is down, the Bark process has crashed, or the device key is invalid — the heartbeat stops pinging and Vigilmon alerts after 60 minutes.

Step 8: Configure Alert Channels

  1. Go to Alert Channels in Vigilmon and add your preferred channel (email recommended as the primary — so you still get alerts even if your phone's Bark app is the thing that's broken).
  2. For the Bark HTTP availability monitor: Consecutive failures before alert = 2.
  3. For the APNs TCP connectivity check: Consecutive failures before alert = 3 — Apple's APNs endpoints occasionally have brief regional hiccups that self-resolve.
  4. For TLS certificate expiry: use both email and Slack so the alert reaches someone even if one channel is down.
  5. For the cron heartbeat: Vigilmon's default (miss one interval → alert) is appropriate.

Summary

| Monitor | Target | What It Catches | |---|---|---| | HTTP server | :8080 / HTTPS | Bark process crash | | Delivery endpoint | /push response time | APNs latency, slow delivery | | TLS certificate | Bark domain | Certificate expiry, app connectivity break | | Database | API response body | BBolt/SQLite corruption or lock | | APNs TCP | api.push.apple.com:443 | Firewall blocking APNs outbound | | Rate limiter | HTTP status 429 alerts | Overly aggressive rate limit config | | Cron heartbeat | End-to-end delivery | Full pipeline failure detection |

Bark's value is that you control the notification pipeline — but that control means you own the reliability too. With Vigilmon watching your HTTP server, APNs upstream connectivity, TLS certificates, and end-to-end delivery, you'll know when your self-hosted notification stack breaks before you notice a suspicious silence from your automations.

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