FAQ - Frequently Asked Questions

That is the smallest part of what we do. There are four types of monitors to choose from:

• HTTP/HTTPS - we fetch the address and grade the server's response. Classic availability monitoring.
• Port (TCP) - we open a connection to a given port. For anything that is not a website: a mail server, a NAS, a database.
• DNS - we ask the resolver about a record of your domain and compare the answer with what you expect.
• API (JSON) - we compare the shape of an endpoint's response against a recorded contract.

On top of an HTTP monitor you can additionally enable page content checks, SSL certificate monitoring and a daily health audit that detects regressions after changes to the site. That last one is what sets us apart from a plain pinger.

Yes, there are two free routes:

• The Free plan - no time limit, with a smaller number of monitors and without some of the additional features. It does not require a payment or any declaration that you will pay later.
• A 30-day trial of any paid plan - so you can test the features the Free plan does not include (the health audit, for example).

When the trial ends, your monitors are not deleted. The account moves into a state where checks are suspended until you choose a plan, and your historical data waits for you. Current limits and prices are listed on the pricing page.

The number of monitors depends on your plan - the exact figures are on the pricing page and in the billing section, where you can also see your current usage („X of Y used").

You cannot exceed the limit by accident: trying to add one monitor too many gives you a message rather than a silent charge. You then have two options - remove a monitor you no longer need, or move to a higher plan.

Some features have their own separate limits, independent of the monitor count: content monitoring and API monitors are allocated as a pool within your plan, because they cost considerably more than a plain availability check.

That depends on the interval, which you set separately for each monitor - anywhere from one minute to twelve hours. For production sites the usual choice is 1 or 5 minutes.

Add a short confirmation on top of that: before we declare a site down, we repeat the check. This is why a single network hiccup does not wake you up at night. In practice, with a one-minute interval you get an alert about a real outage within 1 to 3 minutes of it happening.

We send the recovery alert just as quickly, so you know not only that something went down, but also that it is back up.

There are three channels and you can enable any combination of them:

• E-mail - the basic one, it always works.
• Browser push notifications - the fastest option while you are at your computer.
• Phone notifications via ntfy - a free app for Android and iOS. In your profile you generate a private, hard-to-guess topic and subscribe to it in the app.

We do not send SMS messages and we do not plan to. An ntfy notification arrives just as fast, costs nothing, and lets us avoid charging you for message bundles.

You set your channels once in your profile, and then decide per monitor which events you want to hear about: downtime and recovery, an expiring certificate, a drop in site health.

You install nothing. There is no plugin, no script and no agent to deploy on your server - you simply provide an address. Everything happens from the outside, exactly the way a visitor's browser does it.

The load is negligible. A plain availability check is a single lightweight HTTP request. Content monitoring downloads the page in full, but has a hard cap on how much data it will read, and the health audit runs once a day.

For comparison: one single person browsing your site usually generates more traffic than our monitoring does in an entire day.

This is the most common report we get, and it is almost always one of the following:

1. A firewall, WAF or Cloudflare is blocking our requests. Your browser has cookies and history, our monitoring does not - to a protection layer it looks like a bot. The fix: add our IP addresses to your allow list (see the next question).
2. An SSL certificate error. Expired, self-signed, or not matching the address. A browser shows a warning you can click through; monitoring does not click - and treats it as downtime. The monitor's details page shows the exact reason.
3. The response time limit was exceeded. The site responds, but more slowly than the configured timeout. Check the response time chart - if it has gone up, this is not a false alarm but a real performance problem.
4. Geographic blocking or rate limiting on a server that treats regular requests as suspicious.
5. Browser cache. You are being served a cached version, while we fetch the page fresh every time. Check it in a private window.

The monitor's details page, in the check history, always shows the specific reason (response code, certificate error, timeout) - that is the first place worth looking.

The addresses we send requests from are public and you will find them in the app, next to the monitor's settings. It is worth adding them to your allow list if:

• you run a firewall, a WAF or ModSecurity that blocks repetitive traffic,
• you use Cloudflare or a similar service with an aggressive protection mode,
• you have a security plugin that bans IPs after a series of requests (a common case with WordPress),
• you are monitoring a resource restricted to selected addresses.

Without this, the first false alarm usually shows up within a few days of adding the monitor - and it is not a site outage, just your protection doing its job.

In order, starting with the most common cause:

1. Notification channels in your profile. We only send alerts to the channels enabled under „My profile". If none are enabled, no alert goes out - we show a warning about this in the alert settings.
2. Alerts on the monitor itself. Channels are one thing, consent for specific events is another. Check whether availability alerts are ticked for that monitor.
3. Push notifications blocked by the browser. If you once clicked „Block", the browser will not ask again. Click the padlock in the address bar, set the notification permission to „Allow" and reload the page.
4. An ntfy topic that does not match. The topic in the ntfy app has to be identical to the one in your profile, on the same server. There is a „Send test" button - the fastest way to check.
5. E-mail in the spam folder. It happens with the first message. Add our address to your contacts.
6. The monitor is paused. A paused monitor is not being checked, so there is nothing to generate an alert from.

Availability monitoring answers the question „is the site up". Health answers the question „is it working as well as it did yesterday".

Once a day we audit the page across five categories: availability, security, SEO, best practices and performance (based on Core Web Vitals from real Chrome user measurements). We compare the result with the previous audit and show you the difference.

The important part is that you do not get yet another report listing a hundred things to fix. The history is kept as a change log: an entry appears when something broke, got fixed or changed, plus one control entry per week. Among other things we detect a sudden noindex, disappearing security headers, mixed content, a longer redirect chain, a changed page title or a removed Cache-Control header.

For every regression we show the context from the same time window: whether the page content changed, whether headers disappeared, whether the server changed, how much the HTML grew. That is usually enough to point at the cause.

Regression alerts are triggered by the page's own score, calculated without Core Web Vitals data - those can move without any change on your side, and we do not want to wake you up for that.

You enable it on an HTTP monitor with a single switch. From that moment on:

• we check the certificate's expiry date and show it on the monitor's details page,
• we warn you 30, 14 and 7 days before it expires,
• a certificate error (expired, not matching the address, self-signed, untrusted) marks the site as down, because for a visitor that is exactly what it is.

If you deliberately use a self-signed certificate, for example in an internal environment, you can enable the option to ignore certificate errors. The site will then not be marked as down for that reason, and we still monitor the expiry date. Just keep in mind that browsers will show your visitors a warning anyway.

You add a DNS monitor, point it at a name and a record type (A, AAAA, CNAME, MX, NS, TXT, CAA, SRV), and then enter the values you expect. We ask the resolver and compare the answer.

There are three matching modes:

• contains - every declared value must be present in the answer, extra records are fine. The safe default.
• exact - the answer must be exactly what you declared. This is the only mode that catches a record added by somebody else, which is what tampering with a zone looks like.
• exists - the record simply has to be there and not be empty, with no value comparison.

The most common uses: an A record, so you know the domain points at the right server (handy during a migration); an MX record, because mail disappearing shows no visible symptom on the website; and a TXT record with your SPF, so your messages do not start landing in spam.

When something does not match, the monitor's details page states plainly what we expected and what the resolver returned.

Yes, that is what the port (TCP) monitor is for. You provide a host and a port number, and we open a connection and measure how long the handshake takes. If the connection completes, the service is up.

This has one practical advantage over checking a web panel over HTTP: the web interfaces of such devices can be slow to wake up and produce false alarms even though the device was reachable the whole time. A port answers immediately.

If the monitored device sits on a slow link and you still get occasional misreads, enable the reduced sensitivity option - the monitor then gives the host more time to respond before declaring it unreachable.

It is a monitor for endpoints that return JSON. When you create it, we record the shape of the response: which fields it contains and what type they are. On every check we compare the current response against that contract.

What matters is what we do not compare: values. A changed article title or a different number in a field is not an incident. A field that disappeared, or a changed type, very much is.

This catches the failure you cannot see from the outside: the API answers with 200 and the application consuming it breaks anyway. Typically after a module or plugin update.

We support GET and POST (deliberately not PUT, PATCH or DELETE - a monitor runs for years and will not modify your data). For GraphQL you type the query itself and we wrap it in valid JSON for you. You can also add simple conditions on selected fields, for example that the path errors must not exist - GraphQL happily answers with a 200 even when the backend is down.

Every monitor can be paused. A paused monitor is not checked and will not send alerts.

Importantly: we record the pause window in the history and exclude it from the uptime statistic. A planned maintenance window therefore does not damage your availability figure, and you do not have to explain in a report where the sudden 97% came from.

On the monitor list and on the „Needs attention" screen a paused monitor is clearly marked, together with how long the pause has been running - so that you do not pause something before a deployment and switch it back on a month later.

That depends on your plan - the exact retention period for statistics is listed on the pricing page for each plan.

Regardless of that, you always have:

• the availability timeline for the last 90 days on the monitor's details page,
• a list of events and incidents with start times, durations and reasons,
• the check history,
• the health audit history, with the score over time and a day-by-day response time chart.

After moving to a higher plan, data starts being kept longer from the moment of the change. We cannot recover what has already been deleted under the previous plan.

Yes, that is what the Team section is for. The model is simple:

• A team member has their own, independent account - you do not share a login, and they cannot see your settings or your billing.
• You invite them by the e-mail address of an account that already exists in the system. Their plan does not matter, because receiving a share costs nothing.
• You share selected monitors, not everything at once.
• They see the statuses and statistics of the shared monitors and set up their own alerts on their own channels. As a result an outage reaches two people, and whoever is available reacts.
• By default they can only view - they will not change or delete anything. If you need to give more, there is a separate editor permission: it allows changing the settings of shared monitors, but not adding new ones or deleting existing ones.

The number of team seats depends on your plan. An invitation that has been sent but not yet accepted also takes up a seat.

Create a public status page. You pick which monitors appear on it, give it a name and a short description, and get a ready URL to pass on.

You can protect it with a password if it should not be available to everyone who has the link.

This solves two things at once: the client stops asking „is it down for you too?", because they check for themselves, and they can see that somebody really is watching their services. With maintenance contracts, that is the simplest proof that the service is being delivered.

One thing to keep in mind about how sharing works: a status page gets the monitors you select at that moment. A monitor added later will not appear on it automatically.

Three things worth doing straight away:

• Projects. Group your monitors, for example one project per client or per environment. The homepage, key subpages, DNS records and services of a single client, all on one screen.
• Adding several addresses at once. When setting up monitoring for a new site you enter a dozen or so addresses in one step instead of clicking through them one by one.
• Sensible names. The monitor's name appears in alerts, so „Shop - cart" tells you far more at three in the morning than a bare URL.

On top of that there is the „Needs attention" screen, which shows only what requires a reaction: what is down, what recovered, whose certificate is expiring. With a larger number of monitors, that is the only screen you need to look at daily.

Not at the moment. All checks run from our default location and there is no option to select another country or region.

In practice this does not matter for most use cases: a server outage, an application error, an expired certificate or a changed DNS record look the same from anywhere in the world. The differences show up mainly in response times, and we measure those always from the same point - which is precisely what makes the „today versus your baseline" comparison trustworthy.

Location selection is on our roadmap. If it matters to you, let us know - requests like these genuinely influence what we build next.

You change your plan in the billing section. Moving up takes effect immediately and unlocks the limits and features right away.

When moving down we never delete anything quietly. Before you confirm the change, we show you an exact list of consequences, for example:

• how many monitors exceed the new plan's limit,
• how many team members have to be removed and how many shares that will revoke,
• which features will stop working and on how many monitors (certificate monitoring, health audit, content monitoring, API monitors).

Only after reviewing that list do you decide. You pick and remove the monitors over the limit yourself - we do not choose them for you.

You sign in with an e-mail address and a password, and you additionally have:

• Two-factor authentication (2FA) based on an app with one-time codes, such as Google Authenticator or Aegis. When enabling it you receive recovery codes in case you lose your phone, and you can regenerate them at any time.
• A list of active sessions in your profile. You can see where you are signed in and end any session remotely - useful after logging in on somebody else's computer.

Changing your e-mail address requires confirmation through a link sent to the new address, so taking over a signed-in browser is not enough to take over the account.

Signing in with a Google or Microsoft account is not available at this time.

We store only what is needed to provide the service: account data (e-mail address, name), monitor configuration, check results and event history, plus billing details if you are on a paid plan. You will find the specifics in our privacy policy and GDPR information.

You delete your account yourself, from your profile. The process has two steps: we send a confirmation code to your e-mail address, and only entering that code deletes the account. This protects against both an accidental click and somebody else's.

Deleting an account is irreversible. All of your monitors disappear together with their check and audit history, and access for the people you shared monitors with is revoked. The accounts of your team members are untouched - they are independent and have their own plans and their own sites.