Monitoring Your Anytype Self-Hosted Sync Server with Vigilmon

Anytype's self-hosted sync server is a distributed stack of Go microservices — any-sync-coordinator, any-sync-filenode, any-sync-consensusnode, plus MongoDB and Redis — that together enable cross-device sync with end-to-end encryption. Each process can fail independently and silently: clients may appear to sync locally while quietly queuing changes that never reach other devices. Vigilmon lets you watch every layer from a single dashboard so you catch failures before users lose data or notice stale content across devices.

What You'll Set Up

• TCP monitors for all three sync node services (coordinator, file node, consensus node)
• HTTP health endpoint monitors for each sync node API
• TCP monitors for MongoDB and Redis
• TLS certificate expiry monitors for each sync endpoint
• Disk space cron heartbeat for the file node storage volume
• Alerting policy for the full sync stack

Prerequisites

• Anytype self-hosted sync server deployed (all three any-sync-* services running)
• Default ports: coordinator 4830, file node 4730, consensus node 4930
• MongoDB accessible (default port 27017)
• Redis accessible (default port 6379)
• A free Vigilmon account

Step 1: Monitor the Sync Coordinator

The sync coordinator (any-sync-coordinator) manages the sync topology and peer discovery. It is the entry point clients use to find the other nodes. If it goes down, new devices cannot join the network and existing clients eventually lose their node maps.

1. Log in to vigilmon.online and click Add Monitor.
2. Set Type to TCP Port.
3. Set Host to your sync server's hostname or IP.
4. Set Port to 4830.
5. Set Check interval to 1 minute.
6. Click Save.

For a deeper check, the coordinator exposes a gRPC-over-TCP API. If your coordinator also serves an HTTP metrics endpoint (common when metrics.addr is configured in coordinator.yml), add an HTTP monitor:

1. Click Add Monitor → HTTP / HTTPS.
2. Set URL to http://your-server:4830/metrics (adjust port/path to your config).
3. Set Expected HTTP status to 200.
4. Set Check interval to 1 minute.
5. Click Save.

# Quick manual check
nc -zv your-server 4830 && echo "Coordinator reachable"

Step 2: Monitor the File Node

any-sync-filenode stores and serves user media, attachments, and binary blobs. It is the most disk-intensive component. If it goes down, file uploads and downloads silently fail while text sync continues — users see missing images and attachment errors.

1. Click Add Monitor → TCP Port.
2. Set Port to 4730.
3. Set Check interval to 1 minute.
4. Click Save.

If your file node exposes an HTTP health endpoint:

1. Click Add Monitor → HTTP / HTTPS.
2. Set URL to http://your-server:4730/health (or the metrics path from your config).
3. Set Expected HTTP status to 200.
4. Click Save.

Step 3: Monitor the Consensus Node

any-sync-consensusnode maintains distributed consensus for collaborative editing and conflict resolution. If it becomes unavailable, concurrent edits from multiple devices may not merge correctly.

1. Click Add Monitor → TCP Port.
2. Set Port to 4930.
3. Set Check interval to 1 minute.
4. Click Save.

All three TCP monitors together give you a complete view of which node failed when clients report sync problems.

Step 4: Monitor MongoDB

All three sync nodes use MongoDB as the primary datastore — coordinator node maps, file node metadata, and consensus logs all live there. A MongoDB failure stops all node write operations even if the Go processes themselves are still running.

1. Click Add Monitor → TCP Port.
2. Set Host to your MongoDB server.
3. Set Port to 27017.
4. Set Check interval to 1 minute.
5. Click Save.

Pair this with a cron heartbeat for a deeper check that verifies MongoDB accepts connections:

# Add to cron on the database host
* * * * * mongosh --quiet --eval "db.adminCommand({ping:1})" anytype \
  && curl -s https://vigilmon.online/heartbeat/YOUR_MONGO_HEARTBEAT_ID

Create a matching Cron Heartbeat in Vigilmon with a 1 minute expected interval and 2 minute grace period.

Step 5: Monitor Redis

Redis provides caching and session management for the sync nodes. A Redis failure degrades node performance and can cause authentication failures for sync sessions.

1. Click Add Monitor → TCP Port.
2. Set Host to your Redis server.
3. Set Port to 6379.
4. Set Check interval to 1 minute.
5. Click Save.

For a logic-level health check, use a cron heartbeat:

# Add to cron on the server
* * * * * redis-cli ping | grep -q PONG \
  && curl -s https://vigilmon.online/heartbeat/YOUR_REDIS_HEARTBEAT_ID

Step 6: Monitor TLS Certificates for Sync Endpoints

Anytype enforces end-to-end encryption and verifies TLS on all sync connections. An expired certificate causes all connected clients to immediately drop sync with a TLS handshake error — they will appear to work locally but cannot reach your server.

For each sync endpoint that serves TLS, add a certificate expiry monitor:

1. Click Add Monitor → HTTP / HTTPS.
2. Enter the HTTPS URL for the endpoint (e.g., https://coordinator.yourdomain.com).
3. Enable Monitor SSL certificate.
4. Set Alert when certificate expires in less than 21 days.
5. Click Save.

Repeat for the file node and consensus node endpoints. With 21-day advance warning, you have three renewal cycles before expiry even with Let's Encrypt's 90-day certs.

Step 7: Monitor Disk Space on the File Node

The file node accumulates user attachments continuously. A full disk causes binary writes to fail, which appears to clients as upload errors while text sync continues working — a confusing split-brain state.

Add a cron heartbeat that only pings Vigilmon when disk usage is below a threshold:

#!/bin/bash
# /usr/local/bin/filenode-disk-check.sh
MOUNT="/var/lib/anytype/filenode"   # adjust to your data volume
THRESHOLD=85                         # alert if usage >= 85%

USAGE=$(df "$MOUNT" | awk 'NR==2 {print $5}' | tr -d '%')

if [ "$USAGE" -lt "$THRESHOLD" ]; then
  curl -s https://vigilmon.online/heartbeat/YOUR_DISK_HEARTBEAT_ID
fi

Schedule it in cron:

# /etc/cron.d/anytype-disk
*/10 * * * * root /usr/local/bin/filenode-disk-check.sh

In Vigilmon:

1. Click Add Monitor → Cron Heartbeat.
2. Set Expected ping interval to 10 minutes.
3. Set Grace period to 5 minutes.
4. Copy the heartbeat URL into the script above.
5. Click Save.

When disk fills above 85%, the heartbeat stops — Vigilmon alerts you before writes fail.

Step 8: Monitor External Reachability of Sync Nodes

Clients on mobile and remote devices must reach your sync endpoints from the internet. Your server may be up locally while a firewall rule or DNS issue blocks external access.

Add HTTP monitors that probe each endpoint from Vigilmon's external probes:

1. Click Add Monitor → HTTP / HTTPS.
2. Use the public HTTPS URL for each sync service endpoint.
3. If the endpoint returns a non-200 on GET (gRPC health endpoints often return 405), set Expected HTTP status to 405 or use TCP Port monitoring instead for raw reachability.
4. Set Check interval to 1 minute.
5. Click Save.

Since Vigilmon probes from outside your network, a passing check confirms that internet clients can reach the service — something a local monitoring tool cannot verify.

Step 9: Configure Alert Channels

1. Go to Alert Channels in Vigilmon and add Slack, email, or a webhook.
2. Set Consecutive failures before alert to 2 for TCP monitors on the sync nodes (brief network interruptions are normal during deployments).
3. Set it to 1 for the MongoDB and Redis TCP monitors — a database failure should alert immediately.
4. Set TLS certificate monitors to alert at 1 failure (expiry is a state, not a flap).
5. Set the disk heartbeat to alert at 1 missed ping.

Summary

| Monitor | Target | What It Catches | |---|---|---| | Coordinator TCP | :4830 | Peer discovery failure, node map unavailable | | File node TCP | :4730 | Binary upload/download broken | | Consensus node TCP | :4930 | Collaborative merge broken | | MongoDB TCP | :27017 | All write operations halted | | Redis TCP | :6379 | Session and cache failures | | Coordinator TLS | https://coordinator.domain | Certificate expiry breaks all client connections | | File node TLS | https://filenode.domain | Media sync TLS failure | | Consensus node TLS | https://consensus.domain | Consensus TLS failure | | Disk heartbeat | Cron every 10 min | File node disk full — uploads failing | | External reachability | Public HTTPS URLs | Firewall or DNS blocking remote clients |

Running Anytype's self-hosted sync stack gives you complete control over your data, but it means you own the reliability of five services that clients silently depend on. With Vigilmon watching each layer, you'll know the moment sync breaks — before your users notice their changes have stopped arriving on other devices.