Uptime monitoring: setup, alerts and the Kukie-Uptime checker

What is Kukie-Uptime?

Kukie-Uptime is the uptime checker of Kukie.io, the cookie consent platform. If you found requests like this in your server logs:

Kukie-Uptime/1.0 (+https://kukie.io/docs/uptime-monitoring)

then someone who manages this website in Kukie.io - the site owner, or an agency working for them - has switched on uptime monitoring for it. The checker requests one page of the website from our server at the interval they chose (between once a minute and once an hour), plus a single re-check one minute after any failed check and the occasional manual check started from the dashboard.

It is safe to allow. Each check is one plain HTTP GET request that runs no JavaScript, so it never appears in Google Analytics or other tag-based analytics. The checker records only the status code, the response time and, once a day, the expiry date and issuer of the site's SSL certificate. The page content is read only to recognise a bot-protection challenge and is never stored. Apart from following redirects, it does not follow links, submit forms, log in or crawl the site.

If the checker is being blocked or challenged, see Allowlisting the checker. If you manage the server and want the checks to stop, ask the website owner to switch monitoring off in their Kukie.io dashboard, or contact us.

How uptime monitoring works

Uptime monitoring lives in your Kukie.io dashboard, next to the cookie banner you already run. Once you switch it on for a site, our server requests the site's homepage (or another page you choose on the same domain) on a schedule and records whether it answered, how fast, and why not when it failed. When the site goes down you get an email - and, if you want, a webhook event - telling you what we saw and what to do. When it comes back, a second email tells you how long it was down.

Nothing is added to your website. The checks run from our server, not from a script on your pages, so there is no code to install and nothing changes for your visitors or your cookie banner.

Uptime monitoring is available on selected plans - see the pricing page for which plans include it and how often each plan checks. For an overview of the feature, see Uptime monitoring on our website.

Turning it on

1. Open the site in your dashboard and go to Insights > Uptime in the site's sidebar.
2. Open the Settings tab and switch on Monitor this site.
3. Check the Page to check field. It starts as your homepage; you can point it at another page, as long as it stays on the same domain (or its www. version).
4. Choose a Check interval, add any Additional recipients, and press Save settings.

The first check runs within a minute. The same on/off switch is also available under Site Settings > Uptime monitoring - flip it in either place.

If your plan does not include uptime monitoring, the Uptime page is shown locked, names the plan that includes it, and links to upgrade.

Who can do what

• Every member with access to the site can view the Uptime page and use Check now.
• Only organisation owners and admins can change the settings, see the additional recipients, the webhook URL and its signing secret, and send a webhook test. Other members see how many extra recipients are set, not the addresses.

Choosing the check interval

Checks can run every 1, 3, 5, 15, 30 or 60 minutes. Your plan sets the fastest interval you can use; for each site you can pick that one or any slower one. Intervals faster than your plan allows are shown locked, with the plan that unlocks them.

Whatever interval you pick, a failed check is re-tried one minute later. So even at a 60-minute interval, a real outage is confirmed and alerted about a minute after the first failed check, not an hour later. The interval decides how often a healthy site is checked, and how soon a recovery is noticed while the site is down.

What counts as down

Each check is one request for the page. It counts as up when the page answers with a status code below 400 within 15 seconds.

• Two failures in a row. A single failed check never raises an alarm. We re-check one minute later, and only a second consecutive failure opens an incident and sends the alert, so a one-off network blip never wakes you up.
• Redirects are followed. Up to 5 redirects are followed, and the page they end on must answer below 400. A redirect to a working page is up; a redirect to an error page is down; a redirect loop or more than 5 hops is down.
• Error status codes. Any 4xx or 5xx answer is down - including 404 (page missing), 429 (rate limited), 500 and 503 (for example a maintenance mode page).
• 401 and 403. An "access denied" answer without a bot-protection challenge counts as down, because either your visitors are refused too or a firewall is blocking our checker. If the site loads in your browser, allowlist the checker.
• No answer. Timeouts, refused connections, DNS failures and SSL handshake errors all count as down, and the alert says which one it was.
• IPv4 first. Checks connect over IPv4 whenever your domain has an IPv4 (A) record. IPv6 is used only for sites that have no IPv4 address.

Blocked is not down

Many sites sit behind bot protection (Cloudflare, Akamai, DataDome and others). When our checker receives a bot-protection challenge page ("Checking your browser", "Just a moment...", a "verify you are human" check) instead of your content, the site is marked Blocked by bot protection, not down. Real visitors get through such a challenge, so no incident is opened, no downtime is recorded and no down alert is sent. While the checker is challenged, though, we cannot tell whether the page itself is healthy - allowlist the checker to get real results again.

Reading the Uptime page

The status next to the page title reads Up, Down, Blocked by bot protection, Waiting for first check, Paused or Monitoring off. When something needs your attention, a notice above the tabs says what happened and what to do, whichever tab you are on.

Overview

• Uptime 24h, Uptime 7d and Uptime 30d - the share of time the site was up. Green is 99.9% or more, amber 99% or more, red below 99%. The figures count from the moment monitoring was last switched on.
• Avg response 24h - the average time to fetch the page over the last 24 hours, with the number of checks.
• Incidents 30d - confirmed outages in the last 30 days.
• SSL expires in - days until the site's certificate expires, with its issuer. Amber at 14 days or fewer, red at 7 or fewer.

Below the figures, the daily strip has one cell per day (up to 90 days, or your plan's history window if shorter): green is fully up, amber had under an hour of downtime, red an hour or more, grey was not monitored. Hover a cell for that day's uptime, incidents and downtime.

The Response time chart shows the time to fetch the page's HTML - including the DNS lookup and any redirects, but not images, scripts or styles - averaged per interval over the last 24 hours, 7 days or 30 days. Red dots on the baseline are intervals where every check failed; an amber dot on the line marks an interval where some checks failed. A gap without a dot means the checker only met a bot-protection challenge there, which has no response time to draw.

Incidents

Every confirmed outage, newest first: when it started (the first failed check), when it was resolved (or Ongoing), how long it lasted and its cause in plain words.

Check now

Check now runs a check immediately and shows the result, for example "Up in 312 ms (HTTP 200)". Every site member can use it, up to 30 times per site per day (and 60 times an hour per person across all sites); the scheduled checks are not affected by that limit. Send test event for the webhook has its own allowance of the same size. While monitoring is switched off, Check now still shows the result, but nothing is recorded and no alerts are sent.

Email alerts

When an incident opens, we email a down alert with what we saw (for example "The site did not respond in time." or "The site answered with HTTP 503.") and what to do next. When the site answers again, a back up email tells you how long it was down and why. You get one down alert per outage, not one per failed check. If a site goes down more than 10 times within 24 hours, the further outages are still recorded and still sent to the webhook, but no longer emailed, so a flapping site cannot flood anyone's inbox.

Who receives the alerts:

• The organisation owner, by default. Switch Email the organisation owner off on the Settings tab to stop owner emails for that site, or the owner can mute them for every site under Settings > Notifications > Uptime and SSL alerts.
• Up to 5 additional recipients per site - a developer, an agency inbox or your hosting provider's support address. They always receive the alerts; remove an address to stop them.

The same recipients receive the SSL certificate warnings.

SSL certificate warnings

For https sites, the checker also reads the expiry date and issuer of the site's SSL certificate once a day. You get a warning when 14, 7 and 1 day are left, once each. If a certificate is first seen with, say, 5 days left, the 7-day warning goes out straight away and the 1-day warning later. When the certificate is renewed, the warnings re-arm automatically for the new one.

Most hosts renew certificates automatically; a warning is your cue to check that yours did. If a certificate does expire, browsers can no longer connect securely and the check fails with an SSL error, which opens an ordinary down incident.

Webhook

To send events to your own systems, switch on Webhook on the Settings tab, enter a Webhook URL and press Save settings. A signing secret is generated when you save; owners and admins can Reveal, Copy or Regenerate it. Use Send test event to check the connection - the result appears next to the button.

There is no built-in Slack, Microsoft Teams or PagerDuty integration: the webhook is the integration point, and your endpoint can forward events to whichever tool you use.

Events

• monitor.down - an incident opened (two consecutive failed checks).
• monitor.up - the site answered again; the incident carries its duration.
• ssl.expiring - the certificate reached the 14, 7 or 1 day warning.
• webhook.test - sent by Send test event.

The request

POST {your webhook URL}
Content-Type: application/json
User-Agent: Kukie-Uptime/1.0 (+https://kukie.io/docs/uptime-monitoring)
X-Kukie-Event: monitor.down
X-Kukie-Delivery: 5f0c3b7e-2d1a-4c55-9a3e-8b7d6c1f2e90
X-Kukie-Signature: sha256=<hex HMAC-SHA256 of the raw body>

A monitor.down body, formatted here for reading (it is sent as compact JSON):

{
    "id": "5f0c3b7e-2d1a-4c55-9a3e-8b7d6c1f2e90",
    "event": "monitor.down",
    "occurred_at": "2026-10-01T09:14:03+00:00",
    "site": {
        "id": 12,
        "domain": "example.com",
        "url": "https://example.com"
    },
    "incident": {
        "started_at": "2026-10-01T09:13:02+00:00",
        "resolved_at": null,
        "duration_seconds": null,
        "cause": "timeout",
        "status_code": null
    }
}

• monitor.up carries the same incident block with resolved_at and duration_seconds filled in.
• ssl.expiring carries an ssl block instead: {"expires_at": "...", "days_left": 7, "issuer": "Let's Encrypt"}.
• webhook.test carries only id, event, occurred_at and site.

The cause is one of: timeout (no answer in time), connect (connection refused or dropped), dns (the domain name could not be resolved), tls (the SSL handshake failed), http (an error status - see status_code), redirect (too many redirects), oversized (the response was larger than 5 MB), blocked (the domain resolves to a private network address) or transport (another network error).

Verifying the signature

Compute the HMAC-SHA256 of the raw request body - the exact bytes you received, before any JSON parsing - with your signing secret, prefix it with sha256= and compare it with the X-Kukie-Signature header using a constant-time comparison.

PHP:

<?php
$secret    = getenv('KUKIE_WEBHOOK_SECRET'); // the signing secret from the Uptime page
$rawBody   = file_get_contents('php://input');
$signature = $_SERVER['HTTP_X_KUKIE_SIGNATURE'] ?? '';
$expected  = 'sha256=' . hash_hmac('sha256', $rawBody, $secret);

if (! hash_equals($expected, $signature)) {
    http_response_code(401);
    exit;
}

$event = json_decode($rawBody, true);
// $event['event'] is monitor.down, monitor.up, ssl.expiring or webhook.test.
// $event['id'] equals the X-Kukie-Delivery header: store it to skip retries you already handled.
http_response_code(200);

Node.js (Express):

const crypto = require('crypto');
const express = require('express');

const app = express();
const secret = process.env.KUKIE_WEBHOOK_SECRET; // the signing secret from the Uptime page

// express.raw keeps the body as the exact bytes that were signed.
app.post('/kukie-webhook', express.raw({ type: 'application/json' }), (req, res) => {
    const expected = Buffer.from('sha256=' + crypto.createHmac('sha256', secret).update(req.body).digest('hex'));
    const received = Buffer.from(req.get('X-Kukie-Signature') || '');

    if (expected.length !== received.length || !crypto.timingSafeEqual(expected, received)) {
        return res.sendStatus(401);
    }

    const event = JSON.parse(req.body.toString('utf8'));
    // event.event is monitor.down, monitor.up, ssl.expiring or webhook.test.
    res.sendStatus(200);
});

app.listen(3000);

Delivery rules

• Only a 2xx response counts as delivered. Anything else, or no answer within 10 seconds, is retried twice: after one minute and again after five minutes.
• Redirects are not followed - use the final address as the webhook URL. A 3xx answer counts as a failed delivery.
• The URL must be publicly reachable; private and local network addresses are refused.
• X-Kukie-Delivery equals the payload's id and stays the same on retries, so you can skip a delivery you already processed.
• After Regenerate, update your receiver straight away: the new secret signs every request from then on, including retries of earlier events.

Monthly uptime report

Switch on Monthly uptime report on a site's Settings tab to include that site in the report emailed to the organisation owner on the 1st of each month. The report covers the previous calendar month: one email per organisation with the average uptime, incidents and total downtime across your monitored sites, then one line per site with its uptime percentage, incidents, downtime, average response time and certificate days left. The owner can switch the report off for every site under Settings > Notifications > Monthly uptime report.

Allowlisting the checker

If your firewall, security plugin or CDN blocks or challenges unknown visitors, let our checker through so a block is not reported as downtime. Every check comes from these addresses and carries this User-Agent:

• IPv4: 46.62.206.36
• IPv6: 2a01:4f9:c014:ea58::1
• User-Agent: Kukie-Uptime/1.0 (+https://kukie.io/docs/uptime-monitoring)

Allow both addresses: checks use IPv4 whenever your site has an IPv4 address, and IPv6 otherwise. Allowlisting by IP address is the most reliable option - anyone can copy a User-Agent, so treat a User-Agent rule as the weaker fallback. The same values are shown on the Uptime page's Settings tab under Checker details, and in every down alert.

• Cloudflare - add an IP Access Rule with the action Allow for both addresses, or a custom WAF rule that skips the security features for them.
• Wordfence and similar WordPress security plugins - add both addresses to the plugin's list of allowlisted IP addresses.
• Hosting firewalls - ask your hosting provider to allowlist both addresses if you cannot do it yourself.
• Server-log analytics - filter out the Kukie-Uptime User-Agent so the checks are not counted as visits.

Troubleshooting

• The site is reported down, but it loads in my browser. Usually a firewall or security plugin answers our checker with 403, 429 or 503 while letting you through - a Cloudflare WAF rule, Wordfence, a hosting firewall or rate limiting. Check the cause in the alert or on the Incidents tab; for HTTP 401, 403 or 429, or a refused connection, allowlist the checker. For timeouts and DNS errors, ask your hosting provider: a network problem between our server and your host can affect the checks without affecting every visitor.
• The status says "Blocked by bot protection". Your site answered with a challenge page. No downtime is recorded, but the checks cannot see your real page until you allowlist the checker.
• The status says "Paused". Monitoring pauses while the site is frozen, and while the organisation's paid plan has no active subscription (for example after a failed payment). It resumes automatically once the site is active again or billing is restored. No scheduled checks run and no alerts are sent while paused. If the site was down when the pause began, that incident is closed at the last check that saw it down, so the pause adds no downtime.
• I don't see Uptime in the sidebar, or the page is locked. Uptime monitoring is available on selected plans; the locked page names the plan that includes it.
• The webhook test fails. "Not delivered: the endpoint redirected" means the URL redirects - use the final address. "The URL is not publicly reachable" means it points at a private or local address. "The endpoint did not answer in time" means it took longer than 10 seconds. If requests arrive but your signature check fails, make sure you hash the raw body rather than re-encoded JSON, and that the receiver has the current secret.
• Planned maintenance. A maintenance page usually answers 503, which counts as down. Switch Monitor this site off for the maintenance window and on again afterwards (see the questions below).
• SSL expires in shows n/a. The page is checked over http, or the certificate has not been read yet. If the certificate cannot be read, the card says "not available" and no certificate warning is ever sent on a guess.

Frequently asked questions

Does the checker affect my analytics or my cookie banner?

Not for tag-based analytics such as Google Analytics: the checker runs no JavaScript, so tracking tags never fire and your cookie banner never loads for it. Analytics that read your server logs will see the requests; filter them by the User-Agent.

Does it add anything to my website?

No. The checks run from our server. Nothing is added to your pages and your cookie banner script is unchanged.

Where are the checks made from?

From a single location: our server. The two-failure rule is what stops a brief network blip between our server and yours from raising a false alarm.

Can I monitor more than one page per site?

One page per site: the homepage by default, or any other page on the same domain.

Can I get alerts by SMS, Slack or phone?

Alerts are sent by email. For anything else, use the webhook: your endpoint receives every event and can forward it to Slack, Microsoft Teams, PagerDuty or a similar tool. There is no built-in integration with those tools.

How long is the history kept?

Incidents are kept for 30, 90 or 365 days depending on your plan, and the daily strip shows up to 90 days of it. Raw check data, which powers the response-time chart, is kept for 30 days.

Can I pause the checks during planned maintenance?

Yes: switch Monitor this site off, and on again when you are done. Uptime percentages then count from the moment you switch it back on; past incidents stay on the Incidents tab. If the site was down when you switched off, that incident is closed at the last check that saw it down.

What does uptime monitoring not do?

It is deliberately simple: it checks one page per site from one location over HTTP(S). It does not check from multiple locations, look for specific words on the page, run TCP, ping, DNS or port checks, watch your domain's expiry date, publish a public status page, or measure your real visitors' experience.