Your SilverBullet knowledge base went offline at 11 PM. The SQLite database lock crept in after a botched sync, and the server process silently exited. You woke up to a blank screen and six hours of inaccessible notes.
SilverBullet is a self-hosted, open-source structured note-taking and knowledge management platform built around Markdown. It runs as a single Node.js process, stores your notes in SQLite, and is accessed entirely through the browser. That simplicity is its strength — and its blind spot. When the process crashes, nothing restarts it automatically unless you've configured a process manager. Vigilmon gives you the external eye that tells you when SilverBullet has gone dark before your next writing session becomes a recovery session.
This tutorial sets up end-to-end monitoring for a self-hosted SilverBullet instance.
What You'll Build
- A Vigilmon HTTP monitor on SilverBullet's web interface at port 3000
- A keyword check to confirm the app loaded, not a proxy error page
- A heartbeat monitor to verify the server process is alive
- SSL certificate alerts for proxied deployments
Prerequisites
- A running SilverBullet instance (default port 3000, or proxied via Nginx/Caddy)
- A free account at vigilmon.online
Step 1: Monitor SilverBullet's Web Interface
SilverBullet serves its entire UI from a single HTTP endpoint. When it is running and healthy, a GET request to the root path returns the app shell with a 200 status. When the process has died or the SQLite database is locked, the server returns nothing or a 502 from your reverse proxy.
Test the endpoint:
curl -I http://your-server:3000/
Expected:
HTTP/1.1 200 OK
content-type: text/html
Set up the Vigilmon monitor:
- Log in to Vigilmon and click New Monitor → HTTP.
- Set URL to
http://your-server:3000/(orhttps://notes.yourdomain.com/if proxied). - Set Check interval to 60 seconds.
- Set Expected status code to
200. - Save the monitor.
Vigilmon now checks SilverBullet's availability every minute from multiple regions.
Step 2: Keyword Check to Confirm App Load
A reverse proxy misconfiguration or a stale service worker can serve a cached error page with a 200 status. A keyword check on the response body confirms that SilverBullet's actual application HTML is being returned, not an error shell.
SilverBullet's HTML response includes a distinctive <title> element and script references that won't appear on a generic Nginx 502 or Caddy error page.
- Click New Monitor → HTTP in Vigilmon.
- Set URL to your SilverBullet URL.
- Set Expected status code to
200. - Under Advanced → Keyword check, configure:
- Keyword present:
SilverBullet - Keyword absent:
502 Bad Gateway
- Keyword present:
- Save.
This monitor will fire if your proxy is up but SilverBullet itself has crashed, because the proxy's error page won't contain "SilverBullet".
Step 3: Heartbeat Monitor to Confirm the Server Process
SilverBullet is typically started with a command like silverbullet /path/to/notes and kept alive by PM2, systemd, or a Docker restart policy. If the process manager itself has a configuration error, the process may not restart after a crash.
A Vigilmon heartbeat monitor works in reverse: your server calls Vigilmon's ping URL on a schedule, and Vigilmon alerts you if the ping stops arriving. Add a cron job or a systemd timer on the SilverBullet host:
# crontab -e
* * * * * curl -fsS https://vigilmon.online/api/heartbeat/<your-heartbeat-id> > /dev/null 2>&1
Set up the heartbeat:
- In Vigilmon, click New Monitor → Heartbeat.
- Set Expected interval to
60 seconds. - Set Grace period to
120 seconds. - Copy the ping URL shown and paste it into your cron job.
- Save.
Now, if your VPS reboots, the process manager fails, or the host goes offline entirely, the pings stop and Vigilmon alerts you within two minutes.
Step 4: SSL Certificate Alerts for Proxied Deployments
Most SilverBullet deployments sit behind Nginx or Caddy for TLS termination. Caddy handles renewal automatically, but Nginx with Certbot can fail silently if the renewal cron job isn't healthy or the domain's DNS has changed.
When your HTTPS monitor is configured on the public domain (Step 1 or 2), Vigilmon automatically checks the SSL certificate on every request. To configure certificate expiry alerts specifically:
- Open the HTTP monitor you created in Step 1.
- Go to Advanced → SSL certificate monitoring.
- Enable Alert when certificate expires within and set it to
30 days. - Save.
You'll receive an alert 30 days before expiry, giving you time to renew before browsers start showing security warnings to anyone opening your notes.
Step 5: Alert Channels
Go to Notifications → New Channel in Vigilmon:
- Email — direct alerts to you
- Webhook — post to Slack or Discord
A typical SilverBullet alert looks like:
🔴 DOWN: notes.yourdomain.com
Status: 502 Bad Gateway (keyword "SilverBullet" not found)
Region: EU-West
Triggered: 2026-01-15 23:14 UTC
Recovery notification:
✅ RECOVERED: notes.yourdomain.com
Downtime: 6 hours 12 minutes
What You've Built
| Scenario | How Vigilmon catches it | |---|---| | SilverBullet process crash | HTTP monitor detects 502 from proxy | | SQLite database lock (server exits) | HTTP monitor detects non-200 or keyword miss | | Proxy up but app crashed | Keyword monitor misses "SilverBullet" in body | | Process manager failure after reboot | Heartbeat ping stops arriving | | SSL certificate expiry (Nginx + Certbot) | Certificate expiry alert fires 30 days before | | DNS misconfiguration | HTTP monitor detects DNS resolution failure | | VPS host offline | Heartbeat and HTTP monitors both fire |
SilverBullet's lightweight design makes it a joy to run — but "lightweight" also means no built-in health dashboard and no automatic recovery. Vigilmon fills that gap with external monitoring that works whether your notes are on a local machine, a cheap VPS, or a Raspberry Pi.
Start monitoring your SilverBullet instance today — register free at vigilmon.online.