I’m using API calls to monitor the status of my small Syncthing cluster. This is meant to simulate a glance at the Syncthing web console and seeing that all of my Folders and Remote Devices are in the “Up to Date” status.
So far I’m checking:
/rest/noauth/health – I’m parsing this for “OK” on the system doing the status monitoring – If Syncthing is down, it stops here and reports an error.
/rest/system/connections – I’m parsing this for the “connected” attribute for each remote Device. If the other Devices are connected, good, otherwise investigate.
/rest/db/completion – I’m running this with each remote Device and Folder specified, and parsing for the “completion” percentage – if all Folders are at 100, good, otherwise investigate.
I mainly just monitor if every folder is 100% in sync. If they aren’t, then one or more nodes aren’t working properly.
Due to having a mix of LAN, WAN and VPN connections, it’s not unusual to see the occasional temporary disconnect, so I found the signal-to-noise ratio from /rest/system/connections tended to distract from other alerts.
Syncthing has been so rock solid that I sometimes forget it’s there. I don’t recall ever seeing /rest/noauth/health return anything but "OK’, so I’m not even sure what it would mean when it isn’t.
One thing I haven’t automated yet is alerting when there are file conflicts.
I check the health endpoint to see if Syncthing has stopped running on that Device for any reason – I’d rather have my monitoring stop there to throw an error in that case.
I check connections because if they go down it’s a symptom of something Bad likely happening in my environment. So far, if one is down and I don’t know why already, that’s been true.
My best automation for file conflicts is rudimentary at best: it checks each Folder for files containing .sync-conflict- in their names and lists them. I’ll give this some more thought.
I like to use STC CLI tool to monitor my Syncthing farm. Though I do miss something fundamental on/offline that easily integrates in Uptime Kuma or so.
IIRC, the API overhaul was considered but the decision was made to move forward without that. Getting off the old database and onto SQLite was the higher priority, the way I read those threads here.