tutorial

Monitoring Notesnook with Vigilmon

Notesnook is an end-to-end encrypted, self-hosted note-taking app — with a sync server, API, WebSocket layer, and authentication service all running on your infrastructure. Here's how to monitor every component with Vigilmon.

Notesnook is a privacy-first, end-to-end encrypted notes app with a self-hosted sync server option. When you run your own Notesnook sync server, you take ownership of everything — sync availability, authentication, WebSocket connections, and database health. Any of those can fail independently. Vigilmon lets you watch every layer from a single dashboard so you know immediately when your encrypted notes infrastructure goes dark.

What You'll Set Up

  • HTTP uptime monitoring for the sync server API (port 5264)
  • Health endpoint probe for internal service status
  • WebSocket connectivity monitoring
  • Database availability check
  • Authentication service health monitor
  • Instant alerts for any failure

Prerequisites

  • Notesnook sync server running (TypeScript/Node.js) on port 5264
  • A free Vigilmon account

Why Notesnook Monitoring Matters

A self-hosted Notesnook sync server is the bridge between your devices and your notes. When it fails, clients can still work offline — but as soon as you try to sync, create a note on a second device, or restore from a fresh install, the missing sync server becomes a problem. Silent failures are the biggest risk here:

  • Sync server down — clients queue changes locally but sync silently fails; you won't notice until you switch devices
  • WebSocket disconnected — real-time sync stops working; changes accumulate in the queue and conflicts can build up
  • Authentication service failure — new logins, token refresh, and device registration stop working; existing sessions may still function briefly
  • Database unavailable — all note data is inaccessible; sync requests fail with server errors
  • API returning errors — clients receive 5xx responses and stop syncing without user-visible indication

Each of these is a different failure mode. Monitoring only the homepage misses most of them.

Step 1: Monitor the Sync Server API

The Notesnook sync server listens on port 5264 by default. Add an HTTP uptime monitor to confirm the server is running and responding to requests:

  1. Log in to vigilmon.online and click Add Monitor.
  2. Set Type to HTTP / HTTPS.
  3. Enter http://your-notesnook-host:5264.
  4. Set Check interval to 1 minute.
  5. Set Expected HTTP status to 200.
  6. Click Save.

If you've placed a reverse proxy (nginx, Caddy, Traefik) in front of the sync server, monitor both the proxy URL and the direct port 5264 address. A misconfigured proxy is one of the most common failure points after sync server upgrades.

Step 2: Monitor the Health Endpoint

The Notesnook sync server exposes a health check endpoint that confirms the server is initialized and accepting requests. This is your most important probe — a single check that reflects server readiness without needing to authenticate.

  1. Click Add Monitor → HTTP / HTTPS.
  2. URL: http://your-notesnook-host:5264/health
  3. Expected status: 200
  4. Check interval: 2 minutes
  5. Save.

Verify the endpoint response manually:

curl http://your-notesnook-host:5264/health

If the endpoint returns a JSON status body, add a Body match to the monitor:

  • Expected body contains: "status":"healthy" (or the exact key returned by your version)

This single check catches initialization failures, dependency errors, and configuration problems that the root URL check would miss.

Step 3: Monitor WebSocket Connectivity

Notesnook's real-time sync relies on WebSocket connections. When the WebSocket layer fails, clients don't receive push notifications and fall back to polling — or stop syncing entirely. The failure is silent from the user's perspective until they notice notes are out of date.

Add a TCP connectivity monitor to confirm the WebSocket port is open:

  1. Click Add Monitor → TCP.
  2. Host: your-notesnook-host, Port: 5264.
  3. Check interval: 2 minutes.
  4. Save.

TCP connectivity to the same port as the HTTP API is a lightweight signal that the Node.js process is alive and accepting connections. If your deployment separates the WebSocket listener onto a dedicated port, add a second TCP monitor for that port.

For a deeper WebSocket probe from a shell:

# Confirm WebSocket upgrade handshake completes
curl -i -N \
  -H "Connection: Upgrade" \
  -H "Upgrade: websocket" \
  -H "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" \
  -H "Sec-WebSocket-Version: 13" \
  http://your-notesnook-host:5264/

A 101 Switching Protocols response confirms the WebSocket server is functioning.

Step 4: Monitor Database Availability

The Notesnook sync server uses a database backend (MongoDB by default in self-hosted setups) to store encrypted note data and sync state. If the database becomes unavailable, all sync operations fail and clients receive server errors.

For MongoDB:

Add a TCP connectivity monitor:

  1. Click Add Monitor → TCP.
  2. Host: your-notesnook-host (or the database host if running separately).
  3. Port: 27017.
  4. Check interval: 2 minutes.
  5. Save.

For PostgreSQL (if using an alternative backend):

  1. Click Add Monitor → TCP.
  2. Host: your-notesnook-host, Port: 5432.
  3. Check interval: 2 minutes.
  4. Save.

If your database runs in the same Docker Compose stack as the sync server and is not exposed on a host port, rely on the /health endpoint from Step 2 — a healthy database connection is typically a prerequisite for a healthy sync server response.

Step 5: Monitor the Authentication Service

Notesnook's sync server handles authentication, token issuance, and device registration. If the auth subsystem fails, users can't log in, devices can't refresh tokens, and new device enrollments fail. Existing sessions may continue briefly until tokens expire.

Monitor the authentication endpoint directly:

  1. Click Add Monitor → HTTP / HTTPS.
  2. URL: http://your-notesnook-host:5264/users (or the auth-specific route in your sync server version).
  3. Expected status: 405 or 404 — a response (even a method-not-allowed) confirms the auth router is active.
  4. Check interval: 5 minutes.
  5. Save.

Adjust the expected status code to match what your sync server version returns for a GET on that route. The goal is to confirm the auth layer is responding, not to authenticate successfully.

Step 6: Configure Alert Channels

  1. In Vigilmon, go to Alert Channels → Add Channel.
  2. Add email, Slack (paste your incoming webhook URL), or another channel.
  3. For the sync server and health endpoint monitors, set Consecutive failures before alert to 2 — brief restarts during upgrades are normal.
  4. For the database and authentication monitors, set to 1 — a single failure is worth knowing about immediately.
  5. Enable the alert channel on all monitors.

Alert example:

🔴 DOWN: notesnook-sync.yourdomain.com/health
Status: 503 Service Unavailable
Detected: 2 minutes ago

Summary

| Monitor | Target | What It Catches | |---|---|---| | Sync server API | :5264 | Node.js process down, container crashed | | Health endpoint | /health | Initialization failure, dependency errors | | WebSocket port | :5264 TCP | Real-time sync layer unavailable | | Database | :27017 or :5432 TCP | All note data inaccessible | | Auth service | /users route | Login, token refresh, device enrollment broken |

Notesnook puts your encrypted notes on your own hardware. Vigilmon makes sure the sync server that bridges your devices stays healthy — so your notes are always where you left them.

Get started 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