Focalboard is Mattermost's open-source answer to Trello and Notion — a self-hosted project management board you can run on your own infrastructure. It's a compelling alternative to SaaS tools, but self-hosting means you're responsible for keeping it running. Focalboard depends on a database backend (PostgreSQL or SQLite), a WebSocket server for real-time collaboration, and the Go web server itself. If any of those layers fail, your team loses access to their boards with no support line to call. Vigilmon gives you external uptime monitoring that watches Focalboard from outside your server and alerts you the moment something breaks.
What You'll Build
- A Vigilmon HTTP monitor on Focalboard's
/api/v1/healthendpoint - A keyword assertion to confirm the backend is genuinely healthy
- A heartbeat monitor for database write verification
- WebSocket endpoint reachability check
- SSL certificate expiry alerts (if running behind a reverse proxy)
Prerequisites
- A running Focalboard instance accessible over HTTPS (Nginx or Caddy reverse proxy recommended)
- A free account at vigilmon.online
Step 1: Verify Focalboard's Health Endpoint
Focalboard exposes a health check API at /api/v1/health on the default port :8000. This endpoint is built in — no configuration required.
curl https://your-focalboard-domain.com/api/v1/health
A healthy Focalboard returns HTTP 200:
{"serverVersion":"7.x.x","edition":"personal-server"}
If the server is down or unresponsive, the connection will be refused. A degraded state (e.g., database unreachable) may still return 200 — which is why adding a keyword assertion in the next step matters.
HTTPS setup: Run Focalboard behind a reverse proxy. Example Nginx config:
server { listen 443 ssl; server_name your-focalboard-domain.com; location / { proxy_pass http://localhost:8000; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } }The
UpgradeandConnectionheaders are required for WebSocket pass-through.
Step 2: Create an HTTP Monitor in Vigilmon
- Log in to Vigilmon → Add Monitor → HTTP.
- URL:
https://your-focalboard-domain.com/api/v1/health. - Check interval: 60 seconds.
- Response timeout: 10 seconds.
- Expected status:
200. - Click Save.
Vigilmon begins probing your Focalboard health endpoint every 60 seconds from an external network — independent of your server's own uptime monitoring.
Step 3: Add a Keyword Assertion
A 200 status confirms the HTTP server responded, but not that Focalboard's internals are intact. Add a keyword assertion to verify the response body.
In the same monitor:
- Keyword:
serverVersion - Keyword must be present: yes
This fails the check if a reverse proxy intercepts the request and returns an error page, or if Focalboard is in a partial startup state that still serves an HTTP 200.
Step 4: Monitor Database Connectivity
Focalboard supports PostgreSQL (recommended for multi-user deployments) and SQLite (single-user or small teams). Either way, a database outage means boards won't load and changes won't save.
For PostgreSQL, set up a Vigilmon heartbeat monitor:
- Add Monitor → Heartbeat.
- Name:
Focalboard DB heartbeat. - Expected ping interval: 5 minutes.
- Grace period: 2 minutes.
- Copy the generated heartbeat URL.
Add a cron job that queries the database and pings the heartbeat only on success:
# /etc/cron.d/focalboard-db-heartbeat
*/5 * * * * root \
psql "postgresql://user:pass@localhost:5432/boards" -c "SELECT 1" -q --no-psqlrc > /dev/null 2>&1 && \
curl -fsS -X POST https://vigilmon.online/api/heartbeat/YOUR-HEARTBEAT-ID
For SQLite, verify the database file is readable and not corrupted:
# /etc/cron.d/focalboard-sqlite-heartbeat
*/5 * * * * root \
sqlite3 /opt/focalboard/focalboard.db "SELECT 1" > /dev/null 2>&1 && \
curl -fsS -X POST https://vigilmon.online/api/heartbeat/YOUR-HEARTBEAT-ID
If the database goes offline or the SQLite file becomes locked, the cron job fails and the heartbeat stops — Vigilmon alerts you within 7 minutes.
Step 5: Verify WebSocket Server Uptime
Focalboard's real-time collaboration features (live board updates across multiple users) depend on a WebSocket connection to the server. A WebSocket failure means users see stale data and changes from teammates don't appear until they manually refresh.
You can check WebSocket reachability from the command line using websocat or curl:
# Test WebSocket upgrade (should return 101 Switching Protocols)
curl -i -N \
-H "Connection: Upgrade" \
-H "Upgrade: websocket" \
-H "Sec-WebSocket-Version: 13" \
-H "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" \
https://your-focalboard-domain.com/ws/onchange
For ongoing WebSocket monitoring, add a second Vigilmon heartbeat driven by a periodic WebSocket handshake check:
# /etc/cron.d/focalboard-ws-heartbeat
*/5 * * * * root \
curl -s -o /dev/null -w "%{http_code}" \
--max-time 5 \
-H "Connection: Upgrade" -H "Upgrade: websocket" \
-H "Sec-WebSocket-Version: 13" \
-H "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" \
https://your-focalboard-domain.com/ws/onchange | grep -q 101 && \
curl -fsS -X POST https://vigilmon.online/api/heartbeat/YOUR-WS-HEARTBEAT-ID
Step 6: SSL Certificate Monitoring
Add an SSL monitor to get alerted before your certificate expires:
- Add Monitor → SSL Certificate.
- Domain:
your-focalboard-domain.com. - Alert when: certificate expires within 14 days.
An expired certificate causes browser security warnings that block your users from accessing their boards entirely — this monitor catches renewal failures before that happens.
Step 7: Configure Alerting
In Vigilmon under Settings → Notifications:
| Trigger | Channel | Action |
|---|---|---|
| /api/v1/health returns non-200 | Email + Slack | Restart: systemctl restart focalboard |
| Response timeout (> 10 s) | Email | Check Go logs: journalctl -u focalboard -n 50 |
| Keyword serverVersion missing | Email | Check reverse proxy config |
| DB heartbeat misses | Email | Check PostgreSQL/SQLite status |
| WebSocket heartbeat misses | Email | Check Nginx WebSocket proxy headers |
| SSL expires within 14 days | Email | Renew certificate immediately |
Alert after: 1 consecutive failure. Focalboard is not a flapping service — if the health endpoint fails, it needs attention.
Running Focalboard as a systemd Service
# /etc/systemd/system/focalboard.service
[Unit]
Description=Focalboard Server
After=network.target postgresql.service
[Service]
Type=simple
User=focalboard
WorkingDirectory=/opt/focalboard
ExecStart=/opt/focalboard/focalboard-server
Restart=always
RestartSec=5
[Install]
WantedBy=multi-user.target
sudo systemctl enable --now focalboard
With systemd auto-restart and Vigilmon external monitoring, your coverage looks like:
- Focalboard crashes → systemd restarts within 5 seconds
- If the restart fails, Vigilmon detects the outage within 60–120 seconds and alerts you
- You SSH in and check
journalctl -u focalboard -n 100
What Vigilmon Catches That Server Logs Miss
| Scenario | Server logs | Vigilmon | |---|---|---| | Go server crash | May log panic | HTTP monitor fires within 60–120 s | | PostgreSQL connection pool exhausted | DB error logs | DB heartbeat stops; alert fires | | WebSocket proxy misconfiguration | Nginx error log | WS heartbeat stops; alert fires | | SSL certificate expired | Nothing logged | SSL monitor alerts 14 days early | | VPS unreachable from internet | Logs inaccessible | External Vigilmon still detecting outage |
Focalboard's self-hosted model puts your team's project data under your control, but that control comes with responsibility. Vigilmon gives you the external monitoring layer to catch outages, database failures, and WebSocket degradation before your team notices them — and tells you exactly which layer failed.
Start monitoring your Focalboard instance in under 5 minutes — register free at vigilmon.online.