Skip to content
Start free Sign in

Website uptime monitoring

Know when your site goes down.

Kukie.io checks your page from our server as often as every minute and confirms a failure with a second check a minute later. Then it tells you what went wrong and what to do.

See pricing Read the uptime guide

How it works

Every check lands in one of 3 places.

On every check our server requests the page you chose, follows up to 5 redirects and reads the answer. Only one of the 3 outcomes can ever send you an alert.

Every check

Our server requests your page

One plain GET, with no JavaScript, of a page on your own domain.

  • Up

    Final status below 400

    Redirects are followed, and the page they end on answered.

    Then: the next check runs at your interval.

  • Blocked

    A challenge page

    Bot protection answered instead of your content.

    Then: no downtime and no alert. The dashboard shows what to allow.

  • Failed check

    No usable answer

    A timeout, a refused connection, a DNS or TLS failure, or a 4xx or 5xx status.

    Then: a re-check 60 seconds later, whatever the interval.

    Fails again: an incident opens and the alert goes out. Passes: a blip, and nothing is sent.

Redirects are followed, not trusted

A 301 to a working page is up. A redirect that ends on an error page is down, and a loop is reported as one. A bare redirect is never taken as proof the site works.

Your analytics stay clean

A check runs no JavaScript, so Google Analytics and other tag-based tools never count it. Server-log analytics can filter it by the Kukie-Uptime/1.0 User-Agent.

Any page on your domain

Check the homepage, or point the monitor at your shop, sign-in or checkout page instead, anywhere on the site's own domain or its www version.

Fewer false alarms

Two failed checks, one alert.

A single failed request proves very little: a deploy restarting PHP, a brief network hiccup, a host rebooting. So we check again a minute later, whatever your interval, and only a second failure opens an incident.

  1. 10:00 Up Checked on schedule
  2. 10:15 First failure Nothing sent yet
  3. 10:16 Confirmed Email and webhook sent
  4. 10:31 Still down No repeat alert
  5. 10:46 Back up 31 minutes of downtime
  6. 11:01 Up On schedule again
An example on a 15-minute interval. The incident starts at the first failed check, so the downtime you see is the real downtime, not the moment the alert went out.

  • Fast, whatever the interval

    The confirming re-check is always 1 minute after the first failure. A site checked every 30 minutes still gets its alert about a minute after going down.

  • One alert per outage

    While the site stays down you are not emailed again on every check. The next message is the one saying it is back, and for how long it was gone.

  • Blocked is not down

    When bot protection answers with a challenge page, your visitors are fine. We report it as blocked, record no downtime and show you what to allow.

Alerts

Each alert names the cause and next step.

'Your site is down' is not enough to act on at 7am. Whoever reads the alert, whether you, a developer or a client, knows whether to call the host or check the firewall.

  • Did not respond in time. The server is overloaded or not responding.
  • Connection refused or dropped. The web server or the host is down.
  • Domain name could not be resolved. A DNS or domain registration problem.
  • TLS (SSL) handshake failed. Often an expired or invalid certificate.
  • HTTP 500, 502, 503… The application, or a proxy in front of it, is failing.
  • Too many redirects. A redirect loop, often after a settings change.

Alerts go to the organisation owner and to up to 5 more addresses per site, such as a developer, an agency inbox or the client. The owner can turn them off in their notification settings, and the extra recipients get them until you remove the address. If one site goes down more than 10 times in a day, further outages are still recorded and sent to the webhook, but no longer emailed.

SSL certificates

Expiry warnings before visitors see one.

An expired certificate does not take your server down. It does something worse: every visitor gets a full-page security warning instead of your site, and automatic renewals can fail without anyone noticing.

Once a day, on the same connection as a regular check, we read the expiry date of the certificate your site serves and warn you at 14 days, 7 days and 1 day left. Renew it, and the next daily read picks up the new date and starts the countdown again.

30 days left Expires
  1. 14 days left First email
  2. 7 days left Second email
  3. 1 day left Last email
One email for each band. A renewed certificate starts the countdown again.

In your dashboard

Status, history and settings for each site.

Uptime sits next to your consent analytics in each site's dashboard. The status, and anything that needs your attention, sits at the top of every tab.

  • Overview

    Uptime for 24 hours, 7 and 30 days, average response time, incidents and SSL days left, coloured green, amber or red so a glance is enough. A day-by-day strip and a response-time chart show the trend.

  • Incidents

    Every confirmed outage with its start, end, duration and cause, newest first. How far back it goes depends on your plan.

  • Settings

    The page to check, the interval, who gets alerts, the webhook and the monthly report. Owners and admins edit them. Everyone else on the site can run a manual check.

Webhook

A signed webhook for everything else.

Email suits most sites. When outages need to reach a chat channel, an on-call rota or your own status tooling, turn on the webhook and we send a small JSON event to your endpoint when something changes.

  • Signed with HMAC-SHA256

    Every request carries a signature made with your site's own secret, so your endpoint can reject anything we did not send.

  • Down, up and expiry events

    monitor.down, monitor.up and ssl.expiring, plus webhook.test from the dashboard to try your endpoint.

  • Retried, then recorded

    Only a 2xx counts. A failed delivery is retried twice with backoff, and the last result shows on the Settings tab.

  • Public endpoints only

    The address must be publicly reachable and is checked again when each event is sent. A signed body is never sent on to a redirect.

The request

POST https://hooks.example.com/kukie
Content-Type: application/json
X-Kukie-Event: monitor.down
X-Kukie-Delivery: 5f1c0c9e-8a2d-4f7b-9d61-0e3a2c7b41d8
X-Kukie-Signature: sha256=9c4e1f…b07a

{
  "id": "5f1c0c9e-8a2d-4f7b-9d61-0e3a2c7b41d8",
  "event": "monitor.down",
  "occurred_at": "2026-09-28T10:16:04+00:00",
  "site": {"id": 12, "domain": "shop.example.com", "url": "https://shop.example.com/"},
  "incident": {
    "started_at": "2026-09-28T10:15:02+00:00",
    "resolved_at": null,
    "duration_seconds": null,
    "cause": "http",
    "status_code": 503
  }
}

Verifying it in PHP

$expected = 'sha256=' . hash_hmac('sha256', $rawBody, $secret);

if (! hash_equals($expected, $_SERVER['HTTP_X_KUKIE_SIGNATURE'] ?? '')) {
    http_response_code(401);
    exit;
}

Plans

Check intervals and history by plan.

Uptime monitoring is included in selected plans. Each plan sets the fastest interval its sites may use and how long incident history is kept, and any site can choose a slower interval for a page that does not need checking every minute.

Uptime monitoring check interval and history by plan
Plan Fastest check Incident history
Agency Every 3 minutes 30 days
Unlimited Every minute 30 days

  • Intervals

    Every 1 minute, 3 minutes, 5 minutes, 15 minutes, 30 minutes, 60 minutes. Intervals faster than your plan allows stay visible in the settings, with the plan that includes them.

  • History

    Incidents are kept for 30 days. The response-time chart covers the last 30 days on every plan.

  • Monthly report

    On the 1st of each month the organisation owner gets one email with last month's uptime, incidents and response time for every site that has the report turned on.

Scope

Deliberately simple, and clear about it.

This is uptime monitoring for the people who already look after a site's consent banner: the essentials, done carefully. Here is what it is, and what it is not.

  • What you get

    • HTTP and HTTPS checks of a page on your own domain
    • Outages confirmed by a second check before anyone is alerted
    • The cause in plain words and a next step in every alert
    • Daily SSL certificate expiry warnings
    • Email to the owner plus up to 5 more addresses, and a signed webhook
    • A monthly uptime report for each organisation

  • What it does not do

    • Checks run from a single location. The second-check rule is what keeps a local network blip from alerting you.
    • No port, ping, DNS or keyword checks: one page, one HTTP request.
    • No public status page and no text messages or phone calls. The webhook is the bridge to tools that do those.
    • No real-user monitoring: a consent tool should not report on every visitor's pageviews.

Getting started

Turn it on in 3 steps.

There is nothing to install. The site you already manage in Kukie.io is the site we monitor.

  1. Step 1: Be on a plan that includes it

    Uptime monitoring is a plan feature. On other plans, the site's Uptime page shows which plan includes it.

  2. Step 2: Turn it on for a site

    Open the site's Uptime page, or Site Settings, and turn monitoring on. The first check runs within a minute.

  3. Step 3: Choose who hears about it

    Pick the interval and the page, add extra alert recipients and connect the webhook if your team works in another tool.

The Help Centre guide explains every setting, including what to allow in your firewall so our checker gets through.

Read the uptime guide

Questions about uptime monitoring

How often does Kukie.io check my website?
Each plan that includes uptime monitoring sets the fastest interval its sites may use, and every site can choose that or anything slower: 1 minute, 3 minutes, 5 minutes, 15 minutes, 30 minutes, 60 minutes. Whatever the interval, a failed check is repeated 1 minute later, so a confirmed outage reaches you about a minute after the first failure rather than one full interval later.
Will the uptime checks show up in Google Analytics?
No. A check is one plain HTTP request for your page. It runs no JavaScript, so Google Analytics, Matomo, Plausible and other tag-based tools never see it. Analytics that read your server logs will count the request, and can filter it by its User-Agent, Kukie-Uptime/1.0.
Why is my site shown as blocked instead of up or down?
Blocked means your site answered our checker with a bot-protection challenge page, the kind Cloudflare or a security plugin shows to unknown visitors. Your visitors are not affected and no downtime is recorded, but we cannot see whether the page behind the challenge is healthy. To fix it, add our checker's IP addresses or its User-Agent to the allow list in your firewall or CDN settings. The dashboard lists both.
Do I need to install anything on my website?
No. The checks run from our server and request your page the way a visitor's browser would, so there is no script, plugin or agent to add. If your Kukie.io consent banner is already installed, you turn monitoring on with a switch in the dashboard.
What happens when my site goes down?
After the second failed check in a row, we open an incident and email the organisation owner plus up to 5 extra addresses you choose, with the cause in plain words and what to do next. If you use the webhook, a signed monitor.down event goes to your endpoint at the same moment. When the site answers again, an email and a monitor.up event say it is back up and how long it was down.
Does Kukie.io check my SSL certificate too?
Yes. Once a day the check also reads the expiry date of the certificate your site serves, and you are warned when 14 days, 7 days and 1 day are left. A renewed certificate is picked up on the next daily read, and the warnings start over for it.

Hear about downtime as soon as it is confirmed.

Turn monitoring on in the dashboard. There is no code to add and no agent to install, and nothing changes on your site.

See pricing Contact us

Related features

Uptime monitoring is part of running many sites from one place. These are its neighbours.

See all features

More for people who run websites

Product news, and guides for agencies and teams that look after more than one site.

See all articles

Disclaimer

Kukie.io provides tools to collect and record consent. It is not legal advice, and using it does not by itself make a website compliant with any law.

Listed on

Kukie.io on Trustpilot (opens in a new tab) Kukie.io on G2 (opens in a new tab) Kukie.io on SaaSHub (opens in a new tab) Kukie.io on AlternativeTo (opens in a new tab)