Components, groups and checks

Components

A component is an entry on your page: "Website", "API", "Survival server". Each has a status that either comes from a check or is set by you. You manage them under Dashboard → Services → your status page → Components.

How many components you can add depends on the plan: 5 on Free, 25 on Pro, 100 on Business.

Groups

Groups organise components, for example "Game servers" and "Web". A group has a name and an Order (smaller numbers appear higher up); you order the components inside it the same way. You create groups under Groups with New group. Groups are optional; three components don't need any.

Check types

When you click Add component, you pick the check type in the Check field: Manual, HTTP, TCP, Ping, CitexNode service, DNS, SSL certificate and Heartbeat.

HTTP(S)

You enter the URL, under Expected HTTP status the status code (usually 200; empty means any success) and under Timeout (seconds) a value between 1 and 30. Redirects are not followed: if https://example.com redirects to https://www.example.com, the check gets a 301. So enter the address that answers directly, or expect the redirect code.

TCP

For anything that doesn't speak HTTP: game servers, databases, mail servers. The check tests whether a connection to the port succeeds. Whether the game behind it really lets players in is something a TCP check can't see.

DNS

Checks that your name resolves correctly. You enter the hostname and choose the record type: A, AAAA, MX, CNAME, TXT or NS. The query goes to public resolvers, so you see what your visitors see.

Optionally you fill in Expected value, such as your server's IP or your mail server. That exact value then has to be among the answers; other answers next to it don't matter. Upper and lower case are ignored. For MX you compare only the mail host without the priority (mx.example.com), for TXT the whole text, even when DNS splits it into several parts.

The check fails when there is no answer or the expected value is missing.

SSL certificate

Checks the certificate your server presents: whether the chain is trusted, whether it matches the hostname and whether it is currently valid. The host is enough as a target, e.g. example.com; for a port other than 443 you add it, such as mail.example.com:993.

You set the warning period under Warn from (days before expiry): between 1 and 90 days, 14 by default. That way you notice in time when an automatic renewal is stuck, before your visitors get an error in their browser.

Heartbeat

The other check types query your service from outside. A heartbeat turns that around: your job reports in to us. That suits anything that can't be seen from outside, such as cron jobs, backups or sync scripts.

How to set it up:

1. Add a component with the check type Heartbeat.
2. Under Expected interval (seconds), set how often your job runs, from your plan's shortest interval up to 24 hours.
3. Under Grace period (seconds), set how much later the call may still arrive: 60 seconds by default, up to 24 hours. If your backup sometimes runs longer, the grace period prevents a false alarm.
4. After creating it, the dashboard shows the Heartbeat address under Edit, such as https://acme.statuscx.eu/hb/…. Call it at the end of every run, with GET, HEAD or POST:

curl -fsS -m 10 https://acme.statuscx.eu/hb/…

In your crontab, attach the call with &&, so the job only reports in when it actually succeeded:

*/5 * * * * /path/backup.sh && curl -fsS -m 10 https://acme.statuscx.eu/hb/… >/dev/null

If no call arrives within interval plus grace period, the component turns red (major outage) and an incident opens automatically. The time counts from the last call, or for a new or re-enabled component from that moment. With the next call it is green again immediately.

Per URL, at most one call every 10 seconds counts; more frequent ones get 429 and change nothing.

CitexNode service

If your service runs with us, you pick it from a list: your game servers, bots and other instances, your own vServers and your Deploy projects. The status then comes straight from CitexNode; you don't have to maintain address or port, even when they change.

Interval

How often a component is checked is set per component under Interval (seconds). The shortest interval depends on the plan: 5 minutes on Free, 1 minute on Pro, 30 seconds on Business. The longest is 1 hour, 24 hours for a heartbeat.

When a component turns red

One failure is not enough. Only after two failed checks in a row does the component turn red and an incident opens automatically; your subscribers and webhooks are notified. When the checks succeed again, the incident closes on its own.

For a heartbeat, the deadline from interval and grace period counts instead, see above. An SSL certificate close to expiry only turns the component yellow.

While a maintenance is running, no automatic incident is opened. More about incidents in Incidents and maintenance.

Overall status

At the very top of your page is an overall status. It is always the worst value of the components, the open incidents and a running maintenance. A single red component colours the whole header.

Where checks come from

Checks run from our server in Frankfurt am Main (Firstcolo data centre, address 110.34.38.189). If your firewall blocks outside requests, the check sees that as an outage. DNS checks ask public resolvers; for a heartbeat, the call goes from your server to us.

When the plan gets smaller

A smaller plan deletes nothing. Components above the new limit stay on the page but are no longer checked. Intervals below the new minimum are raised to the minimum.