Monitoring a service or website

Updated 30 Sep 2026

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.

Saying "down" instead of going quiet

The body {"up": 1} is a check-in. Send {"up": 0} and the monitor is marked down immediately, with the cause reported down — no waiting for the missed-check-in window, and the incident log says the service told you rather than went silent. Send {"up": 1} again and it comes back. The values false, "0", "false" and "down" all count as down, so a shell script can pass its result straight through.

This is for the case where the machine that checks in is fine but the thing it watches is not: a till whose card reader has failed, a backup host whose last run errored. Silence still works as before — a monitor that stops checking in is marked down after the missed-check-in window, whether or not it ever sent up: 0.

Two settings in the monitor's Edit panel let you keep your own field names:

• Up/down field — the key Synacl reads for up/down. Default up. Set it to odoo_ok if that is what your service already reports.
• Latency field — the key that feeds the Response column on the Monitors page and the response-time chart. Default response_ms; set it to odoo_ms, db_latency, or whatever your service measures.

Changing either takes effect on the next check-in.

Sending values, not just a heartbeat

You can put anything useful in the body — {"up":1,"queue_depth":12,"backup_age_hours":3} — and then chart it or build threshold rules on it, exactly as you would with a real sensor. Any numeric field becomes a chartable tag once it has been adopted (see below), and the latest value of each adopted tag is shown on the monitor's row.

There is one thing to know about the first push. A heartbeat starts with no tags, because only your service knows what it reports. A field with no matching tag is still accepted, and the value is still recorded — but it cannot be charted or used in a rule until a tag exists whose name is exactly that field. Until then the monitor looks healthy and reports nothing, which is a confusing combination to run into on your own.

So Synacl tells you: the monitor's page shows a banner naming the fields it is receiving and has no tag for, with a button to add them all. Nothing is lost in the meantime — readings recorded before you add a tag become readable as soon as you do.

Field names are the identity of the reading. Renaming a tag later orphans its history and any widget bound to it, so it is worth using the name you mean the first time.

On your phone

In the mobile app, open Fleet → Monitors. Each monitor shows whether it's up, its availability over the last 24 hours, 7 days and 30 days, and its latest response time. Open one for its daily uptime strip, incident log and response-time chart. You can add, edit and delete monitors from the phone too, including heartbeats: the secret appears once, right after you create one, with a button to copy the check-in URL. The ready-to-paste curl and cron lines are on the web app's monitor page.

When a monitor goes down, the push notification says Monitor down: , and tapping it opens that monitor.

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 — whether a probe failed, a heartbeat went quiet, or a heartbeat reported itself down. 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.

Scoping the rule to this monitor is optional. An event rule left unscoped fires for any device or monitor going offline, and each one has its own cooldown, so one monitor failing never silences another. The alert names the monitor either way. Pick the monitor on the rule when its outage deserves different handling — different recipients, or a different severity. See event-triggered rules.

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.