Monitoring a service or website

A monitor is for anything that isn't a Synacl device but that you still want on the same uptime history: a website, an API, a database server, a branch office's point-of-sale machine.

Go to Monitors → Add monitor. There are two kinds, and the right one depends on one question: can Synacl reach it from the internet?

Probe — Synacl checks it

Use this when the thing has a public address. Synacl contacts it on a schedule and records whether it answered and how long it took.

HTTP probe — enter a URL. By default any 2xx response counts as up. You can tighten that:

• Expected status — a specific code, or a range.
• Body contains — text that must appear in the response. Useful when a broken app still returns 200 with an error page.
• JSON path — pull a field out of a JSON response and require a value. Point it at a /health endpoint and require status to equal ok.
• Maximum response time — treat "answered, but took nine seconds" as down.

TCP probe — enter a host and port. Up means the connection opened. Use it for anything that isn't HTTP: a database, a broker, SSH, a service on a fixed port.

Both record response time as an ordinary reading, so you can chart it, put it on a dashboard, and set a rule on it exactly like any other measurement.

The minimum check interval is 20 seconds. Checks come from Synacl's servers, so if the target sits behind a firewall or on a home network, it will not be reachable — use a heartbeat instead.

Private addresses are refused. A probe cannot point at localhost, a 10.x / 192.168.x address, or anything else on a private network. That is a security limit, not an oversight.

Heartbeat — it checks in with Synacl

Use this when the thing is behind a router you don't control, has no public address, or you would rather not open anything up. Nothing needs to be reachable from outside: the machine sends a small request out to Synacl on a schedule, and going quiet is what marks it down.

This is a dead man's switch. It is the right choice for a fleet of shop tills, a machine on a customer's network, or a backup script that should tell you when it stops running.

When you create a heartbeat monitor you get a URL and a secret. Have the machine call it on a schedule — a cron entry is enough:

*/5 * * * * curl -fsS -X POST https://api.synacl.com/ingest/webhook/<monitor-id> \
  -H "Authorization: Bearer <secret>" -H "Content-Type: application/json" -d '{"up":1}'

Set expected interval to how often it will check in. Synacl allows roughly three missed check-ins before marking it down, so a five-minute heartbeat is reported down about fifteen minutes after the last one. The longest interval you can set is one hour.

Treat the secret like a password. If it leaks, rotate it from the monitor's page.

Monitors are devices

A monitor counts against your device allowance as well as your monitor allowance, and it appears anywhere a device does: in rules, in events, on dashboards, in reports. That is deliberate — everything you already know how to do with a device works on a monitor without learning anything new.

Monitor allowances by plan are on the plans page. Heartbeats and probes count the same.

When something goes down

A failing monitor raises device/offline, the same event a real device raises. So the way to be told about it is the ordinary one: create a rule on that event and give it an email, push or webhook action.

An outage appears in the incident log with its start, end and duration, and pulls down the availability figure on that monitor's uptime history.

If a probe fails repeatedly for a long stretch, Synacl stops checking it and tells you — that prevents a permanently dead URL from generating traffic forever. Re-enable it from the monitor's page once the target is back.