Websites & monitoring Available
Uptime Kuma
Every website in schakl. has had a "monitor this" checkbox for years. This is what finally sits behind it: not a message fired into an automation flow, but a monitor that is a record, with a history you can read back and drift you can see.
What you need
- An Uptime Kuma server, version 1.23 or newer; tested against 2.5.0
- For a managed connection: an account on that server, and outbound reach from schakl. to it
- For a linked server: only that the server can reach us. Nothing else
- The Websites or Domains module switched on, since that is what the panels attach to
How to connect it
- 1 Switch Uptime Kuma on under Instellingen → Integraties (Settings → Integrations).
- 2 Add a server under Instellingen → Uptime and choose its kind. Managed means schakl. signs in and may create, change and pause monitors. Linked means we send nothing into that server and only receive what it reports. Linked is not a degraded managed: it is the mode for a client-hosted server behind a firewall, and it delivers most of the value at no infrastructure cost at all.
- 3 For a managed server, fill in the address and your credentials. A session token is stored and never a password; the token is encrypted at rest and does not come back out of the API. If the server sits behind Cloudflare Access or a proxy, fill in the extra connect headers: a service token or a shared secret is exactly that field with a different value, and it is encrypted for the same reason.
- 4 Create one or more profiles. Nobody types interval, retries, resend interval, accepted status codes and notification channels three hundred times. Leave blank the numeric boxes you want to inherit: blank means follow the default, and prefilling a number nobody chose is exactly how a client later asks why their site is polled every twenty seconds.
- 5 If a Kuma was already running, choose Adopt. Its existing monitors are read and you attach them to the website or domain they belong to, instead of recreating all of them and measuring twice for a while.
- 6 Then tick monitor this on a website to have one created, or link by hand to a monitor that already exists.
- 7 Finally set up the alert: an outage can become a notification in schakl., and an automation rule can react to it.
Linked is not a degraded managed
An agency runs one for itself, and a client sometimes runs one we are asked to look after. The linked kind exists for the second case: we hold no session, need no outbound reach and cannot change anything, and yet the client page still gets a status timeline, an alert can still fire and an automation rule can still react, because the traffic runs the other way. Designing as if managed were the only real kind is exactly how you build a feature that works in a demo and for one client.
What was decided and what was observed are kept apart
Uptime Kuma has a web interface of its own, and it is good, so somebody will edit a monitor in it. A message fired once cannot notice that; a mirror can. So both what schakl. decided and what was last observed are stored, in separate fields, and a check reports drift instead of silently overwriting it. Monitor payloads can also carry secrets (a header with a token, a basic-auth pair), so a fingerprint of those is kept rather than the value: enough to see that something changed, without becoming a second place the secret lives.
Profiles, and the three layers that must not fuse
There are three layers and each does something different. Product invariants live in code: an interval below what the server accepts, or a type this version does not have, is clamped whatever happens. The agency's house default is a profile, because a policy compiled into the source is a decision we took for you. And what is true about this one monitor lives on the monitor. Blank means inherit, a value means override, and explicitly clearing it is how you put "follow the default" back. The invariants clamp last, after both the profile and the monitor, so nothing configured can slip under a floor the server would refuse anyway. And a profile can never set a URL: a profile that could would be able to point forty monitors at the wrong host in one save.
Permissions
Grant these to the role that manages this integration (Settings → Roles). Admin-only by default, and never to the client role.
-
uptime.instance.manageAdd, change and remove servers and profiles. Admin only by default, since credentials live here. -
uptime.monitor.readSee monitors and their status on a website, a domain or a client page. -
uptime.monitor.writeCreate, change, pause and link monitors. Only possible on a managed server.
What it deliberately does not do
- On a linked server schakl. can create nothing and change nothing. That is the contract of that kind, not a shortcoming: we send nothing into it.
- A session token is stored and never a password, and never a two-factor secret. If the token expires the screen asks you to reconnect rather than reporting it as an outage.
- Uptime Kuma has no real REST API. The connection runs over the socket its own web interface uses, which is why the range of supported versions is something we watch rather than something that takes care of itself.
- A server on a private address is refused by default, like every outbound target in schakl. If your Kuma runs on your own LAN, an administrator switches that on deliberately.
- What you see here is the status the server reports; it is not a second monitor. If the Kuma itself goes down, schakl. does not know that by itself.
Where to find it Instellingen → Uptime (Settings → Uptime) for the servers and the profiles, and the Uptime card on a website or a domain. On the client page the status sits beside the rest of what runs for that client.
Read the guide