The people who install a cookie banner are usually the same people who get the call when the website stops working: the site owner, the freelancer who built it, the agency that looks after it. Until now, Kukie.io could tell you a great deal about consent and nothing about whether the site was even online. Uptime monitoring is now part of Kukie.io: we check your website around the clock and email you the moment it stops answering, with the cause in plain words and what to do about it.
There is no new vendor to sign up with and no new script to add. The checks run from our server, not from your pages. Each one is a plain request for the page that runs no JavaScript, so nothing changes on your website, nothing reaches your visitors or your cookie banner, and the checks never show up in Google Analytics or other tag-based analytics.
What uptime monitoring does
Switch it on for a site and our server requests its homepage, or another page on the same domain, on a regular schedule - as often as every minute or as rarely as once an hour. Every check records whether the page answered, how fast, and why not when it failed. The site's Uptime page turns that into:
Uptime figures for the last 24 hours, 7 days and 30 days, colour-coded so you can read them at a glance.
A daily strip with one cell per day: green for fully up, amber for under an hour of downtime, red for an hour or more.
A response-time chart over 24 hours, 7 days or 30 days, with failed checks marked on it.
An incident list showing when each outage started, when it ended, how long it lasted and what caused it.
A Check now button for when you have just fixed something.
An alert you can act on
When your site goes down, the email tells you what we saw - "The site did not respond in time", "The site answered with HTTP 503", "The domain name could not be resolved" - and what to do next. If the site loads for you, a firewall or bot protection is probably blocking our checker, and the email lists the exact addresses to allowlist. If it does not load for you either, it is time to call your hosting provider. When the site answers again, a second email tells you it is back and how long it was down.
Alerts go to the organisation owner and up to five extra addresses per site - a developer, an agency inbox or your host's support desk.
Two failures before an alarm
A monitoring tool that cries wolf soon gets ignored. A single failed check never raises an alarm in Kukie.io: we re-check one minute later, and only a second consecutive failure opens an incident and sends the alert. That one-minute re-check happens whatever interval you choose, so even a site checked once an hour is confirmed as down about a minute after the first failed check, not an hour later.
Redirects are followed, never counted as success on their own: the page they end on must answer normally, so a redirect to an error page is down.
Blocked is not down
Many websites sit behind bot protection that shows automated visitors a "checking your browser" challenge. Real visitors get through it, so it is not downtime. When our checker is challenged, Kukie.io marks the site as Blocked by bot protection instead: no incident, no downtime in your figures and no down alert - just a clear notice explaining how to allowlist the checker so it can see your real page again.
SSL certificate warnings
Once a day the checker also reads the expiry date of your site's SSL certificate. You get a warning 14, 7 and 1 day before it expires, once each. Most hosts renew automatically; the warning covers the time one does not, before visitors see a browser security warning instead of your site.
A webhook for your own tools
If you run your own incident tooling, switch on the webhook and we will POST a signed JSON event to your endpoint when a site goes down (monitor.down), comes back (monitor.up) or its certificate is about to expire (ssl.expiring). Every request carries an HMAC-SHA256 signature so you can verify it came from us, and failed deliveries are retried. Your endpoint can pass the events on to Slack, Microsoft Teams, PagerDuty or any other tool you use; there is no built-in integration with those tools.
A monthly report
On the 1st of each month, the organisation owner receives an uptime report for the previous month covering every site with the report switched on: uptime percentage, incidents, total downtime, average response time and days left on the certificate. For an agency, that is a ready-made summary to share with clients.
How to turn it on
Open a site in your dashboard, go to Insights > Uptime, open the Settings tab and switch on Monitor this site. Choose how often to check, add any extra recipients and save. The first check runs within a minute. Owners and admins manage the settings; any site member can see the status and run a check.
The Help Centre guide to uptime monitoring walks through every setting, the webhook format and the checker's IP addresses for firewall allowlists.
Which plans include it
Uptime monitoring is available on selected plans - see the pricing page for which plans include it and how often each plan checks. Your plan sets the fastest check interval, and each site can use that interval or any slower one. History is kept for 30, 90 or 365 days depending on the plan. If your plan does not include it, the Uptime page in your dashboard shows which plan does.
What it deliberately does not do
Uptime monitoring answers one question well: is my site up, and if not, why? Checks run from a single location, and the two-failure rule keeps that reliable. There are no multi-location checks, no SMS or phone alerts (the webhook is the way to route alerts elsewhere), no public status pages, no checks for specific words on a page, no TCP, ping, DNS or port checks, no domain-expiry monitoring and no real-user monitoring - a consent tool should not send your visitors' page views anywhere to measure them.
Read more on the uptime monitoring feature page. If your plan already includes it, you can switch it on for your sites today.
