Hello everyone,
We wanted to address the disruption some of you experienced yesterday and clarify what happened and equally what didn’t.
What went wrong
Our platform routes its HTTPS traffic (for example the website and REST API) through Cloudflare’s network, primarily because we rely on their services for protection against DDoS attacks, malicious bots and sudden traffic spikes.
On 18 November 2025, Cloudflare suffered a substantial incident. They explain that around 11:20 UTC their system began failing to deliver core network traffic after a bug caused one of their “feature files” (used for Bot Management) to grow unexpectedly large and crash a key proxy component. (The Cloudflare Blog) The upshot: many websites and APIs stopped working or returned 5xx error codes. (The Guardian)
Because our HTTPS-services were going through Cloudflare, parts of our platform (notably the website and REST endpoints) became temporarily inaccessible.
What didn’t fail
Our devices (SCK 1.5 onwards) do not route their MQTT connections via Cloudflare in the same way. That traffic goes directly to our ingestion endpoint (or via your broker setup) and is therefore unaffected by the outage of Cloudflare’s HTTP proxy layer. The bottom line: your device data should still have been ingested properly during the incident.
Why we use Cloudflare
We use Cloudflare to:
- mitigate large-scale attacks on our front-end services (a necessity when you operate a citizen-sensing/IoT-platform open to many devices)
- accelerate content delivery for our users globally
- provide a buffer layer so that the origin infrastructure is not directly exposed.
In short: the trade-off is that we rely on a third-party (Cloudflare) for part of our front-end delivery, and if they suffer a systemic issue it can affect our front-end availability.
Our takeaway
- We regret the inconvenience caused by the outage, for services that matter (API, website) we didn’t function fully.
- We are reassured that the device-ingestion path (MQTT) remained intact, which means data collection was not compromised.
- We’ll continue to consider additional resilience measures (for example fallback endpoints, further decoupling of critical ingestion) so that even when a provider like Cloudflare fails, disruption to the platform is minimised.
If you experienced interrupted service (e.g., devices unable to reach the REST API, or website load failures) please reply here and we’ll review specific times / logs. But from our high-level view, the incident was external to the platform (Cloudflare’s network problem), and the device data ingestion path was not impacted.
Thank you for your understanding and patience.
Best,
The Smart Citizen team