Skip to main content
Cookiebot logo

Is Cookiebot Down?

No — Cookiebot is up

Reachable from all 8 checked regions

Average response time: 557ms

Last checked · checks run every 6 hours

Official status page: https://status.cookiebot.com

Cookiebot uptime

100%
Last 7 days
100%
Last 30 days
100%
Last 90 days
346ms
Avg response, 30 days

Measured from multiple regions every 6 hours. Percentages count only checks that returned an availability answer — 11 days measured so far. A dash means that window does not yet hold enough measured days to publish a figure.

30-day history

11-day clean streak
Aug 22: no data
Aug 23: no data
Aug 24: no data
Aug 25: no data
Aug 26: no data
Aug 27: no data
Aug 28: no data
Aug 29: no data
Aug 30: no data
Aug 31: no data
Sep 1: no data
Sep 2: no data
Sep 3: no data
Sep 4: no data
Sep 5: no data
Sep 6: no data
Sep 7: no data
Sep 8: no data
Sep 9: no data
Sep 10: 100.00% uptime, 36 checks
Sep 11: 100.00% uptime, 32 checks
Sep 12: 100.00% uptime, 32 checks
Sep 13: 100.00% uptime, 32 checks
Sep 14: 100.00% uptime, 32 checks
Sep 15: 100.00% uptime, 31 checks
Sep 16: 100.00% uptime, 32 checks
Sep 17: 100.00% uptime, 32 checks
Sep 18: 100.00% uptime, 32 checks
Sep 19: 100.00% uptime, 32 checks
Sep 20: 100.00% uptime, 16 checks
Aug 22 Today
No downtime Partial Downtime Not measurable No data

Reachability by region

Each region runs its own request from a different part of the world. A service can be up for one continent and down for another, which is usually the first sign of a routing or CDN problem.

gru
397ms
DNS 125ms TCP 2ms TLS 10ms TTFB 311ms
iad
215ms
DNS 55ms TCP 1ms TLS 7ms TTFB 181ms
jnb
272ms
DNS 31ms TCP 0ms TLS 9ms TTFB 253ms
lax
973ms
DNS 150ms TCP 2ms TLS 12ms TTFB 803ms
lhr
201ms
DNS 79ms TCP 2ms TLS 9ms TTFB 184ms
nrt
1620ms
DNS 392ms TCP 1ms TLS 9ms TTFB 1377ms
ord
207ms
DNS 25ms TCP 2ms TLS 9ms TTFB 171ms
sin
571ms
DNS 222ms TCP 1ms TLS 10ms TTFB 513ms

What Cookiebot does

Cookiebot is a consent management platform used by websites to show a cookie banner, record what each visitor agreed to, and hold analytics and marketing scripts back until consent is given. Its banner script loads on the customer's own pages from Cookiebot, which makes it a third-party dependency of every page view on a site that uses it.

What an outage looks like

The consent banner does not appear on a site that normally shows one, or appears and fails to record a choice. Because tags are held back until consent is recorded, analytics and advertising scripts may never fire, so traffic data goes quiet while the site itself serves pages normally. Administrators may be unable to sign in to change banner settings or read scan reports.

What to do about it

Read status.cookiebot.com, which reports CMP - Consent Banner, Admin UI, New Admin UI, Cookiebot Manager and Partner API as separate components. The banner row is the one that affects visitors; the admin rows affect only your team. If the banner component is degraded, expect a gap in analytics for the period and note it before someone reads the dip as a traffic collapse.

Is it down for everyone, or just you?

If this page says Cookiebot is up but it is not loading for you, the problem is between you and them. Run a check against any URL from up to 18 cities across three regions to find out where it breaks.

Test it yourself

Related services

Drata
Drata
Secureframe
Secureframe
Optimizely
Optimizely
Cloudflare
Cloudflare

Cookiebot outage FAQ

My site is up but analytics have gone silent. Could that be Cookiebot?
Yes, and it is the failure mode worth knowing about. Cookiebot holds analytics and marketing tags until consent is recorded, so if the consent banner cannot load or cannot register a choice, those tags never fire while your pages serve normally. The result is a clean-looking site with missing data. Check the CMP - Consent Banner row on status.cookiebot.com before investigating your analytics tool.
Does a Cookiebot outage break my website for visitors?
Your pages continue to be served, since they come from your own infrastructure. What changes is the consent layer: the banner may not render, and anything gated behind consent stays off. Depending on how the script is embedded, a slow or failing third-party request can also delay page rendering, so check how your site loads for a real visitor rather than assuming no visible effect.
Am I out of compliance if the banner does not load during an outage?
The practical position during an incident is usually the conservative one: with no consent recorded, consent-gated scripts do not run, so tracking does not happen without permission. This is a general observation about how consent gating behaves and not legal advice. If a compliance obligation depends on the banner being present, record the incident window and raise it with whoever owns that obligation.
Is it Cookiebot or my own tag setup?
Compare scope and timing. A broken tag configuration or a recent change to your consent categories affects one site, often one page template, and coincides with a change you made. A Cookiebot incident affects every site using the service at once. Check the status page first, then compare against your own deployment history before you start editing tag settings.
Will visitor consent choices recorded before the outage still apply?
Consent decisions already stored on a returning visitor's browser are not erased by a service incident, so people who previously made a choice generally keep it. New visitors arriving during an incident are the ones with nothing recorded. Cookiebot does not publish behaviour for every failure mode, so treat the incident window as a period with fewer recorded consents rather than assuming existing ones changed.

How we measure this

  • We request Cookiebot's public endpoint every 6 hours from Fly.io regions across six continents — the most recent check ran from 8 of them.
  • A region counts as down only when it gets no usable HTTP response. A 403 or 429 means the origin answered and refused us, which we report as blocked, never as an outage.
  • A single failing region is treated as probe noise. We only change the verdict when two consecutive cycles agree.
  • Response times average only the regions that actually served the page, so a timeout never inflates the number.
  • Where Cookiebot publishes an official status feed we read it too. An all-clear from the vendor can soften an unconfirmed degradation; a vendor-declared outage only worsens our verdict when our own checks corroborate it.

Get alerted when Cookiebot goes down

This page refreshes every 6 hours. Your own monitors run as often as every 30 seconds, from up to 18 cities across three regions, and tell you the moment something breaks.

Start Free Monitoring
Free plan available No credit card required