AppFlowy is an open-source alternative to Notion — a collaborative workspace for documents, databases, and project management that you can run entirely on your own servers. When your team depends on AppFlowy for daily work, an outage means blocked projects, lost context, and frustrated contributors who can't access their notes.
This tutorial shows you how to set up robust monitoring for a self-hosted AppFlowy instance using Vigilmon — covering the web UI, the real-time sync service, and SSL certificate health.
Why monitoring matters for AppFlowy
AppFlowy Cloud (the self-hosted server component) consists of several pieces that can fail independently:
- The AppFlowy Cloud API — handles authentication, document storage, and user management. If the API goes down, clients can't sync changes and new users can't sign in.
- The real-time collaboration service — AppFlowy uses a WebSocket-based sync service so multiple users can edit the same document simultaneously. If the sync port goes down, users can still open documents but changes from other collaborators stop appearing.
- PostgreSQL and object storage — document content, file attachments, and user data are split across a relational database and object storage. A failure in either layer causes partial or total data unavailability.
- The web interface — AppFlowy Cloud ships a web client. If the static assets are misconfigured or the server errors out, teams without the desktop client are completely locked out.
External monitoring catches failures before your team notices them during active work hours.
What you'll need
- A self-hosted AppFlowy Cloud instance
- A free Vigilmon account
Step 1: Confirm the AppFlowy health endpoint
AppFlowy Cloud exposes a health check at /health. Verify it responds before creating your monitor:
curl -i https://appflowy.your-domain.com/health
A healthy response looks like:
HTTP/2 200
{"message":"AppFlowy Cloud is running"}
If your AppFlowy Cloud instance is behind a reverse proxy, make sure /health is not protected by your authentication layer — it needs to be publicly reachable for Vigilmon to probe it.
Step 2: Set up HTTP monitoring for the health endpoint
- Log in to vigilmon.online and go to Monitors → New Monitor
- Choose HTTP / HTTPS as the monitor type
- URL:
https://appflowy.your-domain.com/health - Check interval: 1 minute
- Under Expected response:
- Status code:
200 - Response body contains:
"AppFlowy Cloud is running"
- Status code:
- Save the monitor
This catches the most severe failure mode — the entire AppFlowy Cloud backend going unreachable.
Step 3: Monitor the web UI separately
The health endpoint confirms the backend is alive, but the web client has its own build pipeline and asset delivery. Add a dedicated monitor for the web interface:
- Add a second HTTP / HTTPS monitor
- URL:
https://appflowy.your-domain.com(or your web client domain if it's separate) - Expected status code:
200 - Assign the same alert channel
This catches broken frontend deploys, misconfigured CDN origins, or static-asset serving failures that leave users with a blank page.
Step 4: Monitor the real-time sync service via TCP
AppFlowy's real-time collaboration layer communicates over a dedicated TCP port (default: 8433 for the WebSocket sync service in AppFlowy Cloud). If this port goes unreachable, connected clients stop syncing — but the HTTP health check still returns 200 because the API itself is fine.
- Add a third monitor: TCP Port type
- Host:
appflowy.your-domain.com - Port:
8433(adjust to your actual sync port if you've changed the default) - Save the monitor
When the TCP check fails, Vigilmon alerts you even though the HTTP health endpoint may still be green. This is the only way to catch sync service crashes without polling the application logs.
Step 5: Set up SSL certificate monitoring
AppFlowy's desktop and mobile clients validate TLS certificates strictly. A lapsed or misconfigured certificate will prevent all clients from connecting — even if the server itself is healthy.
- Go to Monitors → New Monitor
- Choose SSL Certificate
- Domain:
appflowy.your-domain.com - Alert thresholds: warn at 30 days, critical at 7 days
If you're also hosting the sync service on a separate subdomain, add a second SSL monitor for that domain.
Step 6: Configure alert channels
- Go to Alert Channels → Add Channel
- Add a Slack, email, or webhook alert channel
- Assign all monitors to the channel
Recommended alert policy for AppFlowy:
| Severity | Trigger | Action |
|----------|---------|--------|
| Critical | /health returns non-200 for 2+ minutes | Page on-call immediately |
| High | TCP sync port unreachable | Alert team — collaboration is broken |
| Medium | Web UI returns non-200 but API is healthy | Check frontend deploy |
| Warning | SSL cert expires in < 30 days | Schedule renewal |
Monitoring summary
| Monitor | Type | What it catches |
|---------|------|-----------------|
| https://appflowy.your-domain.com/health | HTTP | Backend crash, DB connection failure |
| https://appflowy.your-domain.com | HTTP | Web UI failure, bad CDN config |
| appflowy.your-domain.com:8433 | TCP | Real-time sync service crash |
| appflowy.your-domain.com SSL | Certificate | Imminent TLS expiry |
What's next
- Heartbeat monitors — AppFlowy Cloud runs background jobs for document cleanup and storage management. Add heartbeat monitors so Vigilmon alerts when scheduled tasks stop reporting in.
- Status page — publish a Vigilmon status page for your organization so team members can check whether the workspace is down before filing a support ticket.
- Multiple regions — Vigilmon checks from multiple geographic regions by default, which helps you distinguish a true outage from a regional network issue.
Get started free at vigilmon.online — no credit card, monitors start running in under a minute.