Monitoring

Statuswerk can check your services itself: we call a URL at a fixed interval and tell you when it stops answering. If you like, the check switches the matching component of your status page as well.

Where we check from

Our probes run in six data centres in five European countries, with two independent providers:

  • Hetzner: Falkenstein and Nuremberg (Germany), Helsinki (Finland)
  • UpCloud: Amsterdam (Netherlands), Warsaw (Poland), Madrid (Spain)

Each check alternates between them from run to run. Confirmation always comes from a different region, and whenever possible from the other provider. So neither a problem at Hetzner or UpCloud nor a network issue in one country raises an alert on its own.

A single failure is not an outage. When a run fails, a different region checks again at once. Only when that one fails too does the check count as down and we alert you. That is how we tell "your service is gone" from "a link between us and you is having a moment".

Up again means two successful runs in a row, so a shaky endpoint does not send you twenty mails a night.

Switching regions off: by default every region checks. Under Regions on a check you can switch single ones off, e.g. when your service only needs to be reachable in central Europe or your firewall only admits certain probes. At least two must stay on, otherwise no outage could be confirmed. Confirmation then comes only from the regions you chose. If you pick two at the same provider, the protection against that provider's network trouble is gone. While all regions are on, new ones join automatically. If none of your chosen regions is reachable at the moment, the check waits rather than running from somewhere else.

Each point in the response-time chart comes from the region whose turn it was. Because the regions take turns, the curve jumps with distance: Madrid measures more to a server in Nuremberg than Nuremberg itself. For a calmer curve, choose nearby regions.

Creating a check

Dashboard → Status pages → Uptime monitoring → Create:

  • URL — a public http:// or https:// address on port 80, 443, 8080 or 8443. Internal addresses (e.g. 10.x.x.x, 192.168.x.x, localhost) are refused — see below.

  • Interval — how often we check. How short it may be depends on your plan.

  • Method — GET or HEAD.

  • Expected status — by default any response from 200 to 399 counts as success. We follow redirects (five at most).

  • Keyword (optional) — text that must appear in the response, e.g. "status":"ok". If it is missing, the run fails even when the status is right.

  • Timeout — how long we wait for an answer, 30 seconds at most.

  • Regions — where we check from. All are preselected; at least two must stay on (see above).

  • Authentication (optional) — for pages behind a password:

    • Basic auth with username and password, e.g. an .htaccess/htpasswd protection.
    • Bearer token, sent as Authorization: Bearer …, e.g. for a protected health endpoint.

    This needs an https:// URL, so credentials never cross the internet unencrypted. We store them encrypted and do not show them again after saving. Leaving the field empty while editing keeps the old password or token — unless you change the URL's host or port: then the credentials must be entered again, so they never reach a target they were not meant for. If we are redirected to another host or to http://, the credentials are not sent along. Best create a separate login just for the check, with as few rights as possible.

The first run starts a few seconds after saving.

Connecting it to the status page

A check can belong to a component. You then choose what an outage does:

  • Notify only (default) — you are alerted and decide yourself what to post on the page.
  • Notify and update the component — the component goes to the status you chose (e.g. "Major outage") and back to "Operational" when the check is up again.

Two rules: the check never overrides a status someone set by hand, and it only switches a component back if the component still shows the status the check set.

During maintenance the check stays quiet: while a maintenance affecting its component is in progress, a failure does not count as an outage. Nobody is alerted, the component is not switched, and the check's uptime does not suffer. The overview shows it in blue as "In maintenance". If the service is still unreachable once the maintenance has ended, the next run alerts as usual. If it comes back during the maintenance, the all-clear still goes out. This applies only to checks with a component and only to maintenances that are in progress and published — one still waiting for its second approval does not count.

With "Show on the status page" the check also appears on your page with its measured uptime and a response-time chart — with or without a component.

Who is alerted

Per check you choose:

  • Workspace members — all of them are preselected on a new check. They get the mail in their profile language.
  • Integrations of the status page (Slack, Teams, Discord, Google Chat, webhook).
  • Further email addresses, such as an on-call address — up to ten.
  • SMS numbers in international format (+49…) — up to five, from the Pro plan. SMS alerts count towards your workspace's SMS allowance.

Alerts go out when a check goes down and when it is up again, with the two regions that confirmed the outage and the error (e.g. HTTP 503, "No answer within the timeout", tls: certificate has expired). Common errors are spelled out in mails and chat messages; the API returns them unchanged (timeout, keyword not found) so scripts can check for them.

If an outage ends because you change, pause or delete the check, every recipient gets a short "Outage ended" message — by mail and through the integrations (webhook event monitor.closed), not by SMS. It only says the outage is closed, not that the service is reachable: if it is still down after a change, the next run alerts again.

Recognising our requests

Every request carries the user agent

Statuswerk-Monitor/1.0 (+https://statuswerk.eu/monitoring)

If a firewall or bot protection turns our requests away, allow this user agent. We do not reuse connections, use no proxy and verify the TLS certificate — an expired certificate is an outage to us.

What we do not check

So that nobody can look into other people's networks through us, we do not call internal or reserved addresses — not even when a public name points there or a redirect leads there. Ports other than 80, 443, 8080 and 8443 are blocked.

Looking back at outages

On a check's edit page, Outages lists every confirmed outage: start, end, duration, confirming regions and error. A single failure that no second region confirmed is deliberately not listed.

Pausing, changing, deleting

  • Pausing keeps the check but stops running it. An open outage is ended and a switched component goes back to "Operational" — a paused check should not keep anything red.
  • Changing the URL, method, expected status or keyword starts the check afresh, with the same effect.
  • Deleting removes it along with its outages and response times.

Plans

How many checks you can create and how short the interval may be is in the plan comparison. After moving to a smaller plan we pause the newest checks that no longer fit and raise intervals that are too short. Move up again and they resume on their own — checks you paused yourself stay paused.

Through the API

Everything here works through the API too: GET/POST /api/v1/monitors, PATCH/DELETE /api/v1/monitors/{id} and GET /api/v1/monitors/{id}/outages. Details in the API reference.

Regions are set with regions, a list of codes: fsn (Falkenstein), nbg (Nuremberg), hel (Helsinki), nl-ams1 (Amsterdam), pl-waw1 (Warsaw), es-mad1 (Madrid). null or omitted means all, including future ones. Responses include the regions in effect as regions, and all_regions.

Credentials are set with auth_type (none, basic, bearer), auth_username, and auth_password or auth_token. The password and token are write-only. Responses include only auth.type and auth.username.