# UptimeFlare: serverless uptime monitoring on Cloudflare Workers

> UptimeFlare runs checks from Cloudflare's edge and serves a status page from the same account, with no server to keep alive. The trade-off is that your monitoring now depends on one vendor, and the config file has a history worth reading.

**lyc8503/UptimeFlare** — ✔ Free and serverless uptime monitoring / status page on Cloudflare Workers, with Geo-specific checks

- Repository: https://github.com/lyc8503/UptimeFlare
- Stars: 3,843 · Forks: 611
- Language: TypeScript
- License: Apache-2.0
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/lyc8503-uptimeflare

## What UptimeFlare actually replaces

The project is a status page plus a checker, both running on Cloudflare's edge. The README describes it as a "serverless, and free uptime monitoring & status page solution, powered by Cloudflare Workers", and the practical consequence is that there is no VPS to patch, no container to restart, and no disk to fill. That matters most for small teams and solo operators who want an external view of a handful of services but do not want to become the person on call for the monitoring system itself.

The feature set is deliberately bounded. The README lists up to 50 checks at 1-minute intervals, HTTP/HTTPS and TCP port monitoring, up to 90 days of history, custom request methods, headers and bodies, status code and keyword checks, and notifications through Apprise, which the README says covers 100+ channels. There is also a webhook path for anything Apprise does not reach. The status page side adds a response-time chart, scheduled maintenance and incident history, theme-aware layout, optional password protection, and a JSON API for realtime status.

Who this is not for: anyone monitoring internal-only hosts. Checks originate from Cloudflare's network, so a target that is not reachable from the public internet is invisible to it. The same applies to anything behind an allowlist that does not include Cloudflare's ranges.

## The architecture: Workers, D1, and a Next.js status page

The repository layout shows three cooperating pieces. The worker/ directory holds the scheduled checker that runs on Cloudflare Workers. The pages/, components/ and middleware.ts files form a Next.js 14 application, built for Cloudflare Pages with @cloudflare/next-on-pages, which renders the public status page. Storage moved from KV to Cloudflare D1, and the README's 2026-01-03 note says the migration was made specifically to "resolve long-standing performance issues" and that the data structure was optimized.

Geo-specific checks are the part worth understanding before you commit. The README claims checks from over 310 cities, and the repository contains a proxy/ directory plus a checkLocationWorkerRoute mentioned in the TODO list, which is where the regional dispatch logic lives. In practice this means a single monitor can be evaluated from several vantage points rather than one, which is how you distinguish "the site is down" from "the site is down from Frankfurt."

Deployment is described as Terraform-driven: deploy.tf and .terraform.lock.hcl are at the top level, and the README notes the Cloudflare Terraform provider was updated to v5. That is a real design decision, not a packaging detail. It means the Cloudflare account, the D1 database, and the worker are all described as infrastructure rather than clicked together in a dashboard, which is good for reproducibility and adds a Terraform state file you now have to store somewhere.

## Installing UptimeFlare and running a first check

The README points to the project Wiki for the quickstart rather than inlining steps, so the exact Cloudflare-side commands live there. What the repository does give you is the local and container paths. The package.json defines a dev script for the Next.js front end and a preview script that builds with next-on-pages and serves the output through wrangler pages dev.

To work on the status page locally, install dependencies and start the dev server:

```bash
npm ci
npm run dev
```

For a build that matches the Cloudflare Pages output, the preview script does both steps:

```bash
npm run preview
```

The Dockerfile is the other supported route. It builds the Next.js app with npx @cloudflare/next-on-pages, installs curl and cron in the production stage, and exposes port 8788 with entrypoint.sh as the entrypoint. The README's TODO list marks self-host Dockerfile as done and local deployment docs as still in progress, so treat the container as a supported artifact with thinner documentation than the Cloudflare path.

```bash
docker build -t uptimeflare .
docker run -p 8788:8788 uptimeflare
```

The monitor definitions themselves live in uptime.config.ts at the repository root, with uptime.config.full.ts as the annotated reference. That file is the one to read before deploying, because it is also the file named in the security advisory.

## CVE-2026-29779 and why your commit hash matters

The README carries a security advisory dated 2026-03-04 for CVE-2026-29779. The description is specific: a vulnerability that could expose monitor configuration and credentials in uptime.config.ts to clients. The affected range is stated as versions between 2025-09-21, from commit 41257c6, and 2026-03-04. The advisory recommends upgrading to the latest version.

This is the single most important operational fact about the project, and it deserves a plain reading. A status page is public by default. If the configuration file that drives it contains credentials, and a bug lets those credentials reach clients, the exposure is not theoretical. Anyone running a deployment from that window should treat the credentials in their config as compromised and rotate them, not merely upgrade.

The broader lesson is about where secrets belong. The repository keeps monitor definitions in TypeScript at the root, which is convenient and readable. Any secret you place there inherits the blast radius of the whole deployment. If your checks need an auth header, that header is a credential in a config file, and the config file is the thing that had a disclosure bug.

## Limitations the roadmap admits to

The TODO list is unusually honest and worth reading as a scope statement. Two items remain unchecked: SSL certificate checks, and ICMP via proxy with a question mark. Uptime Kuma users in particular tend to expect certificate expiry warnings, and UptimeFlare does not have them. If cert expiry is the thing that has burned you before, this is not the tool that fixes it.

The second structural limitation is the platform dependency. The README's own framing is that the whole product is powered by Cloudflare Workers, with D1 for storage and Pages for the front end. If Cloudflare has a bad day, your status page has a bad day, and the alerting path may be affected too. A monitoring system that shares a failure domain with the infrastructure it watches is a known compromise, and it is the one you are accepting here.

There is also a documented migration history to weigh. The move from KV to D1 happened on 2026-01-03, and the README says existing users get an "auto migration process." Migrations that rewrite storage are the point where self-hosted deployments break quietly. If you are upgrading an old install rather than starting fresh, follow the Wiki's synchronize-updates page rather than pulling and hoping.

## Uptime Kuma and OneUptime as the alternatives

The searches around this project are full of Uptime Kuma, and the comparison is fair. Uptime Kuma is a self-hosted monitor you run yourself, typically in Docker, which means you own the host, the database, and the uptime of the monitor. UptimeFlare inverts that: you own neither, and you pay with a Cloudflare account instead of a server. If your objection to hosted monitoring is cost, UptimeFlare answers it. If your objection is control, Uptime Kuma answers that, and UptimeFlare does not.

OneUptime appears in the same searches and sits at a different scale. It is a broader observability product, not a single-purpose status page, so the comparison is less about features and more about whether you want one tool for uptime and incidents or a dedicated one. UptimeFlare's incident history and scheduled maintenance are real, but they are the size of a status page, not the size of an incident management platform.

There is a middle case worth naming. If you want a self-hosted checker but not a self-hosted database, the Dockerfile and entrypoint.sh in this repository suggest a local deployment path exists, though the README flags the local deployment docs as work in progress. That path is not the documented default, and the Terraform route is.

## Maintenance cost, licence, and upgrade path

The last push to the default branch was on 2026-06-01, roughly four months before this writing. The repository is not archived. There are no recent releases retrieved, which means versioning is tracked through commits and the Wiki rather than through tagged releases you can pin against. That is a real cost: pinning to a tag is easier than pinning to a commit hash, and the security advisory is written in terms of commits for exactly this reason.

Upgrades follow the Wiki's synchronize-updates page. Given the KV-to-D1 migration and the provider v5 update, the upgrade surface is larger than a typical dependency bump. Budget for reading the upgrade doc before pulling, and for verifying the D1 data after.

Licensing is Apache-2.0, which permits commercial use and modification and includes a patent grant. It also requires that you preserve notices and state significant changes. This is not legal advice; if you are embedding UptimeFlare in a product you distribute, have counsel read the NOTICE and modification clauses rather than taking this paragraph as clearance. The practical implication for most readers is that Apache-2.0 is permissive enough that the licence is unlikely to be the deciding factor.

## Conclusion

Adopt UptimeFlare if you already run Cloudflare and want checks from many cities without operating a host, and if you accept that a Cloudflare outage is also a monitoring outage. Do not adopt it if you need ICMP ping, SSL certificate expiry checks, or a monitor that survives your DNS provider failing. Before deploying, read the 2026-03-04 security advisory and confirm your commit is newer than it, then open uptime.config.ts and verify that every credential you put there is one you are willing to rotate.

## FAQ

### What does uptime monitoring do?

In UptimeFlare's case it means running scheduled HTTP/HTTPS or TCP checks against your services from Cloudflare's network, tracking uptime percentage and response time for up to 90 days, and sending a notification through Apprise when a check fails. The results are rendered as a public status page.

### Is Cloudflare Workers safe?

The README does not treat the platform as the risk, but it does carry a 2026-03-04 advisory for CVE-2026-29779, where monitor configuration and credentials in uptime.config.ts could be exposed to clients in versions from 2025-09-21 to 2026-03-04. Upgrade past that range and rotate any credentials that lived in the config file.

### How much does uptime cost?

The README describes UptimeFlare as free, and it runs on Cloudflare Workers, D1, and Pages rather than on a server you rent. Any charges would come from your Cloudflare account's own usage terms, which the repository does not document.

### What is the best tool for monitoring uptime?

The repository does not rank tools, but the choice it implies is between a self-hosted checker like Uptime Kuma, where you own the host and the database, and a serverless one like UptimeFlare, where you own neither and depend on Cloudflare. UptimeFlare is the better fit when you already run Cloudflare and do not want to operate a host.

## Sources

- [Issues](https://github.com/lyc8503/UptimeFlare/issues)
- [License: Apache-2.0](https://github.com/lyc8503/UptimeFlare/blob/main/LICENSE)
- [lyc8503/UptimeFlare on GitHub](https://github.com/lyc8503/UptimeFlare)
- [README](https://github.com/lyc8503/UptimeFlare/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/lyc8503-uptimeflare