Skip to content
FlareWatch

Docs and changelog for v3.5.0.

Changelog

From CHANGELOG.md in the FlareWatch repo. Newest first.

Changelog

All notable changes to FlareWatch will be documented in this file.

3.5.0

Added

  • The status page sends link-preview tags (Open Graph and a Twitter card) on every page. A shared link now shows the page title and a short description instead of a bare URL. (#99)

Fixed

  • Webhook alerts work again. 3.4.0 told fetch to refuse redirects with a setting that Cloudflare Workers rejects, so every webhook alert failed. Every DNS, flarewatch-proxy and Globalping check failed for the same reason. A redirect now fails the request, as 3.4.0 meant it to, without sending your webhook token or proxy token on to another host. (#101, #102)
  • A Globalping check fails when a poll answers with a redirect or an error. Before, a redirect that carried a finished result could pass the check. (#102)
  • Mattermost and Rocket.Chat alerts show their content. They used Slack’s block layout, which neither app reads, so an alert came through as an empty colored bar. (#102)
  • Sign-in with an OpenID Connect provider or GitHub fails when the token endpoint or GitHub’s API answers with a redirect. Before, it followed the redirect and sent the client secret or the access token along. (#102)
  • The first check run of a new hub ends inside the 30 seconds that Cloudflare gives it. It sends an alert only when the alert can go out in time, and leaves the rest to the next run. A webhook with a timeout of 27 seconds or more always waits for the next run. (#102)
  • The config check fails a webhook with no template whose payloadType is 'param' or 'x-www-form-urlencoded' and that has no payload object. Before, the check passed it and every alert to it failed. (#102)
  • On a phone, a monitor’s 90-day bar no longer draws every day before it has measured how many fit. (#102)
  • An error-change alert that a busy check run had to put off now goes out on a later run. Before, it was lost unless the error changed again. (#102)
  • The hub keeps every row under the 2 MB that Cloudflare documents. History parts are measured in bytes, so long errors in non-Latin scripts no longer make a part too big. The upgrade splits any larger part that 3.2.0 to 3.4.0 wrote, and cuts an incident from before 3.2.0 down to its first and its latest 99 error changes. CI fails a config whose monitor ids are so long that an hour of latency samples could not fit in one row. (#102)

Changed

  • Wrangler 4.149.0, with workerd 1.20261006.1. (#102)
  • The docs say that Cloudflare counts the ping and sign-in limits in each of its locations, and only roughly. Signing out ends the session at once where you are, and can take a minute or more to reach Cloudflare’s other locations. (#102)

3.4.0

A certificate close to expiry now shows its monitor as degraded and sends one warning, instead of taking it down. If a monitor is down today only because of its certificate, its next check closes that outage, and the outage stays in History.

You can roll back to 3.3.0 on the same storage. Take the new fields out of your config first, because 3.3.0 rejects fields it doesn’t know. A certificate inside its warning window then takes its monitor down again.

Read the entries marked Needs attention before you upgrade. Each one changes something you may rely on, or asks you to change a setting.

Added

  • checkEveryMinutes checks a monitor every 1 to 1440 minutes instead of every minute. Monitors with the same interval are spread over different minutes. A monitor that isn’t due keeps its status. reminderEveryChecks still counts check runs, one a minute. (a74ac9a)
  • downAfterChecks opens an outage only after 1 to 10 failed checks in a row. The default is 1, as before. The outage starts at the first failed check of the streak. (a74ac9a)
  • A certificate inside sslCheckDaysBeforeExpiry shows its monitor as degraded and sends one warning for each expiry date. It opens no outage and doesn’t change uptime. A maintenance window pauses the warning. An expired or invalid certificate still fails the check. flarewatch-proxy counts whole days, so it fails a valid certificate in its last 24 hours. (a74ac9a, d1ce297)
  • DNS monitors look up an A, AAAA, CNAME, MX, TXT, NS or CAA record over DNS-over-HTTPS. dnsExpected lists values the answer must hold. They ask cloudflare-dns.com unless you set dnsResolver. See Monitors. (a74ac9a)
  • DOMAIN monitors read a domain’s expiry date over RDAP, once a day. Inside domainExpiryDays, 30 by default, the monitor shows as degraded and sends one warning for each expiry date. An expired domain, a failed lookup or a TLD with no HTTPS RDAP service fails the check. (a74ac9a)
  • notification.summaryAfter sends one message instead of many. When a check run has that many alerts or more for one webhook, from 2 to 50, the webhook gets a single message that lists them. A long list is cut at 1,900 characters and says how many it left out. (a74ac9a)
  • checkProxy: 'vpc' and confirmVia: 'vpc' check a target in your private network through a Workers VPC binding and a Cloudflare Tunnel. Workers VPC is in beta and free on every plan. You add the binding to wrangler.toml yourself. Without it, a vpc monitor fails with an error that says so. See Monitors. (22da72e)
  • /api/badge.svg serves the badge as an image, with the same parameters as the JSON badge. See API, badges and embeds. (5cff0f5)
  • Announcements: the operator posts a notice from History or POST /api/admin/announcements, and it shows on the dashboard under the status banner until it ends. The hub keeps at most 50. See Announcements. (5cff0f5, d1b239c, 032ce34)
  • /feed.atom is an Atom feed of the newest 50 public incidents, maintenance windows and announcements. See Atom feed. (5cff0f5)
  • responseHeaderEquals and responseJsonPath work through flarewatch-proxy 2.0.0 or later, as checkProxy or confirmVia. An older proxy fails these checks with a message that asks you to update it, because it would skip them and pass. See the table in Monitors. (#94)
  • packages/config/src/demo holds the config of demo.flarewatch.app. The deploy uses it only in saminnet/flarewatch, so your fork keeps deploying worker.ts and public.ts. (5cff0f5)

Changed

  • Needs attention. callbacks.onStatusChange runs only when a monitor goes down or comes back up. Before, it also ran when the error text of a down monitor changed. onIncident still runs on every down run. (8c8f6eb)
  • The deploy workflow deploys only from main. Before, running it by hand on another branch deployed that branch. (dfed75e)
  • Needs attention. The deploy warns when HEARTBEAT_SECRET or FLAREWATCH_AUTH_SECRET is shorter than 32 characters, because anyone with one ping URL, or who starts a sign-in, can guess a short secret offline. Replace it with the output of openssl rand -base64 32. A new HEARTBEAT_SECRET changes every ping URL. A new FLAREWATCH_AUTH_SECRET only fails the sign-ins in progress. (b889e5d, b904e7f)
  • Needs attention. Webhook, checkProxy and Globalping requests no longer follow redirects. A redirect fails the request, because each hop spends one of the requests that a check run keeps for checks and alerts. If your webhook or proxy URL redirects, set it to the URL it redirects to. (006a3bb)
  • In light mode, uptime percentages on monitor cards and embeds use darker text, so they pass WCAG AA contrast: about 5:1 on white, up from 2.1:1 to 3.8:1. Status icons, the Check now result, the Ongoing label on incidents and the Info severity badge use the same darker colors. Dark mode is unchanged. The weekday letters in the uptime calendar and the incident times in its day view are now 10px. (#96)

Fixed

  • When a check run can’t afford one request per alert, each webhook now gets the alerts that don’t fit as one summary in the same run. Before, recovery alerts past the run’s 50 requests were never sent, and down alerts waited for later runs. (44511ad)
  • A recovery that a check run has no requests left for now waits for a later run. So does the recovery of an outage that ends while its down alert is still going out, which used to go out in the same run. Before, both could be lost. A waiting recovery is dropped if its monitor goes down again first. (10a3302)
  • Needs attention. A check run no longer starts more checks than its 50 requests allow. The checks that don’t fit skip that minute and keep their status. The starting point moves each minute, so the same checks don’t miss every time. CI now fails a config whose checks due every minute need more than a run has on their own: 47 requests, less one per webhook in the config. A DOMAIN check counts as two. (b203aee)
  • Returning to the dashboard from a monitor page or History no longer makes an extra server call to load collapsed groups. (28eef7a)
  • Hovering a monitor on the dashboard no longer loads its latency. The monitor page loads it once you open it. (6750af6)
  • A Globalping check with sslCheckEnabled now fails with Invalid certificate expiry date when Globalping reports an expiry that isn’t a date. Before, the check passed and stored the broken date. (8f7e464)
  • A monitor id of __proto__ now fails the config check with id cannot be __proto__. (8f7e464)
  • When someone else signs in on the same browser, every open tab of the status page reloads as that account. Before, an open tab could still show the previous account’s private monitors, for example after leaving visitor view. (006a3bb, c8c0b13)
  • The first check run that a page view starts on a fresh deploy now runs once, even when several status-page instances serve the first visitors. (006a3bb)
  • A repeating maintenance window with a start date near the end of the JavaScript date range no longer stops the check runs of every monitor. (006a3bb)
  • When the Worker can’t find its data center, the checks of one run share that failed lookup, and the next run tries again. Before, each check tried again and spent requests that the run keeps for checks and alerts. (006a3bb)
  • A proxy that sends back its FLAREWATCH_PROXY_TOKEN in its location, or as a reply that isn’t JSON, no longer shows the token on the status page or in latency history. (006a3bb, c8c0b13)
  • A sign-in link with a next path such as /.//example.com/ no longer sends you to another site after you sign in. (16e7904)
  • A config with expectedCodes: [], an empty responseKeyword or responseForbiddenKeyword, or responseHeaderEquals: {} now fails the config check, so the unit tests fail and the deploy stops. Before, an empty expectedCodes failed every check with “Expected status , got 200”, and the other three checked nothing. (#94)
  • A target URL with a username and password, such as https://user:secret@example.com, now fails the config check. A Worker dropped them and sent the request without them, so the check never signed in. Send them in headers instead. (#94)
  • A header value that isn’t a string or a number now gets the error headers must map names to strings or numbers. Before, the error was a bare Invalid input. (#94)
  • A direct check now follows redirects itself, with the same rules as flarewatch-proxy. When a target redirects to another site, the Cookie, Authorization and Proxy-Authorization headers from the monitor no longer travel with it. Before, the runtime kept Cookie and Proxy-Authorization. A redirect to a URL with a username and password, or past 20 hops, fails the check. Each redirect counts against the check run’s 50 requests, so a monitor that runs out fails instead of the whole run. (#94, b889e5d)
  • A latency chart with a single sample draws it in the middle instead of at the left edge. (f986eea)
  • /api/badge and /api/badge.svg answer 200 with an unknown badge for a monitor that has no result yet. Before, they answered 404, and some browsers then showed a broken image. A missing or private monitor still gets 404. (#96)
  • An uptime below 100% never shows as 100%. Before, an embed showed 99.96% as 100.0%. Embeds also color a heartbeat monitor’s uptime by its state, as the dashboard does, so a down heartbeat no longer shows green. (#96)
  • Deleting a repeating maintenance window now says that every occurrence goes with it, and shows how it repeats. History lists each occurrence of the window, and the delete button on any of them removes the whole series. (#98)

3.3.0

Deploys no longer check for 1.x data in KV. If you are still on 1.x, follow the 3.0.0 entry below first.

You can roll back to 3.2.0 on the same storage. A repeating maintenance window then shows as a one-off on its first date, and reminders count from the rollback. Nothing is lost, and updating again restores both.

Your config’s monitors are now checked field by field. A misspelt or unknown field, or a field of the wrong type, fails the unit tests and stops the deploy. Before, FlareWatch ignored it.

Added

  • Set maxLatencyMs on a website or API monitor to show it as degraded while its last check is slower than that. It sends no alert, opens no incident and doesn’t change uptime. A maintenance window that covers the monitor keeps it up.
  • /api/data gives each monitor a status: up, degraded, down, pending or running.
  • Check now on a check monitor’s page, for the operator. It runs that monitor’s check once and shows the result there, without saving it. Scripts can do the same through POST /api/admin/check.
  • confirmVia checks a failing monitor once more from a second place, such as your own flarewatch-proxy or a Globalping probe, and records that result. A blip on one network path no longer opens an incident. See Confirm from a second place.
  • responseHeaderEquals checks response headers, and responseJsonPath with responseJsonValue checks one value in a JSON response. See Monitors.
  • Maintenance windows can repeat every day, week or month, on chosen weekdays or a day of the month, until a date or for good. Each run keeps its clock time in the time zone you pick, across daylight saving changes. The dashboard shows the current or next run, and History lists every run. Down alerts, error changes and reminders pause during each run. An outage that alerted before the run still sends its recovery. See Repeating windows.
  • Send a monitor’s alerts to some channels only: give a webhook monitors, a list of monitor IDs. Leave it out and the webhook gets every monitor’s alerts, as before. See Routing.
  • Reminders while a monitor stays down: set reminderEveryChecks on a monitor, at least 30. See Reminders.
  • The status page sends a Content-Security-Policy. Scripts run only from the page’s own origin or with a nonce that changes on every request. See API, badges and embeds.

Changed

  • A late job’s badge says DEGRADED in yellow instead of UP. The badge’s degraded and colorDegraded parameters change that.
  • Embeds show late, pending and running jobs the way the dashboard does.
  • A job that starts again while its outage is still open shows as down until it succeeds, on its row, in the banner and in the API.
  • A monitor that asks its check location for something it can’t do fails with an error that names the setting, and the unit tests fail on it before deploy. Before, sslCheckEnabled on a check from the Worker, or on a proxy check with checkProxyFallback, passed without looking at the certificate, and pingProtocol: 'icmp' outside Globalping quietly ran a TCP check. See the table in Monitors.
  • Every check ends within 55 seconds of the check run’s start. A longer timeout is cut to what is left.
  • A fallback or confirmation check, or an extra Globalping poll, runs only while the run has subrequests to spare under the free plan’s 50, after the hub’s calls and one request per alert webhook. No check sends a request after the run’s 55 seconds.
  • A TCP_PING monitor with expectedCodes, responseKeyword, responseForbiddenKeyword, responseJsonPath, responseHeaderEquals or sslCheckEnabled now fails. Before, it passed on the connection alone.
  • checkProxy: 'worker://...' is gone. Remove it from your config.
  • The admin API rejects a maintenance window with a title, color or monitor list of the wrong type. Before, it dropped the field, and a monitors value that wasn’t a list covered every monitor. A rejected window’s error now says what’s wrong. null leaves a field out when you create a window, as it already cleared one when you update it.
  • The config check rejects a webhook with a field FlareWatch doesn’t know, so a misspelt monitors can’t route every alert to that channel. In FLAREWATCH_WEBHOOKS the Worker logs the field, ignores it and still alerts the webhook.
  • An error change that no webhook accepts no longer counts toward the 5 an outage may send.
  • A Globalping measurement over 1 MiB fails the check, the same limit a direct check puts on a response body. Before, the limit was 4 MiB.
  • A maintenance window’s description can be at most 2000 characters, its title 200, its color 64, and it can list at most 100 monitors with IDs of at most 100 characters. The hub keeps at most 100 windows and refuses a new one past that. You can still edit the ones it has, and a window saved before these limits still shows and pauses alerts.
  • The config check rejects a statusPage field FlareWatch doesn’t know, so a misspelt one fails the deploy instead of being ignored. theme, customCss, themeVars and poweredByUrl are gone from statusPage. The first two did nothing. For themeVars, set the colours in apps/status-page/src/styles.css instead; the :root and .dark blocks at the top hold every variable. The footer link always points to the FlareWatch repository.
  • logo and favicon take a data:image/ URL only for PNG, JPEG, GIF, WebP or ICO. An SVG data URL now fails the config check; use a path or an https: URL to the SVG file instead.
  • logo and favicon take a path, an https: URL or a data:image/ URL. An http: URL now fails the config check, because the page’s Content-Security-Policy blocks images from it.
  • A heartbeat monitor with a field FlareWatch doesn’t know, such as a misspelt graceSecond, now fails the config check, as a check monitor does. Before, FlareWatch ignored it.
  • Heartbeat pings answer 503 when the Worker has no HEARTBEAT_RATE_LIMIT binding. Before, they were taken without a limit. The committed wrangler.toml has the binding, so keep it if you edit that file.
  • A monitor’s page lists maintenance windows up to a year ahead. A window that starts later shows there once it is less than a year away.

Fixed

  • A proxy that reports a latency that is not a finite, non-negative number is treated as an invalid response. Before, one such value made the hub drop every monitor’s samples for that hour.
  • A failed result a proxy reports no longer carries the proxy token into the public error text.
  • A notification.timeZone the runtime does not know fails the config check. Before, it passed, and then every alert failed at send time.
  • A connection failure the runtime reports as “internal error” with a log reference shows as “Connection failed”. The full text stays in the worker’s log.
  • A mass outage no longer loses down alerts to the free plan’s request cap. Alerts a run cannot send wait for the following runs, and waiting does not count as a try. Before, an alert past the cap counted as failed, and after 10 runs it was dropped.
  • vp run dev-status-page serves the page again. Before, the browser got a 500 for a module that imports cloudflare:workers on the server only.
  • The text template called a recovery “still up” when it came in the same second as the outage began.
  • An alert’s target URL no longer carries the user name and password from a monitor’s target.
  • Browsers and proxies no longer cache the page that finishes a provider sign-in and sets the session cookie.
  • The maintenance dialog shows why a window was refused, such as “Too many maintenance windows”, instead of the raw JSON reply.
  • A down alert no longer goes out twice when a stalled check run reports a failed delivery after a later run took the alert over.

3.2.0

The hub moves your history to its new storage once, when it first starts after the update. You can’t roll back to 3.1.0 afterwards.

Changed

  • A monitor that keeps going down and coming back up stays in one outage until it has been up for 15 minutes. The page shows it as down until then, and its recovery alert goes out then. The outage counts as ending when the monitor came back up. Before, each flip wrote several rows, and about 20 flapping monitors could use up the free plan’s daily writes.
  • Error messages are stored up to their first 500 characters.
  • Each monitor keeps at most about 1 MB of incident history. Only a monitor whose long error keeps changing reaches that before 1,000 incidents.
  • Both Workers run on the 2026-09-30 compatibility date, up from 2025-11-17. Wrangler is 4.145.

Fixed

  • A page view reads one row per monitor from the hub, plus a few, however long your history is. In 3.1.0 most page views still read every stored incident, because the hub forgets what it kept in memory a few seconds after each request.
  • A response-time chart reads 13 rows instead of 721.
  • A new incident reads a few dozen rows instead of up to 2,000 for a monitor with a long history.
  • A monitor you change from a heartbeat to a regular check no longer stays down because of the job’s last state.

3.1.0

Changed

  • Each check run reads about a dozen rows from the hub instead of every stored incident, so a long history no longer eats into the free plan’s 5 million rows read a day. Page views and response-time charts read only what changed since the last check run.
  • History drops a maintenance window 90 days after it ends, the same as incidents.
  • A monitor you remove from the config gets its open outage closed. Its history goes after 90 days, like any other.

Fixed

  • A check run that finished after a newer one no longer overwrites the newer results.
  • Response-time charts show only the last 12 hours, even when check runs have stopped.

3.0.0

3.0 removes the code that moved 1.x installs onto 2.x. On 2.x, update as usual. If you’re still on 1.x, update to 2.3.1 first, from a clone of your fork with upstream set up as in Update your fork:

git fetch upstream --tags
git merge v2.3.1
git push

Once that deploy has run, merge upstream/main and push again. If you skip that step, the deploy stops and says so.

Breaking changes

  • 3.0 no longer copies 1.x data from KV into the hub, and the monitor Worker has no KV binding anymore. If KV still holds 1.x data that was never copied, the deploy stops.
  • FLAREWATCH_STATUS_PAGE_BASIC_AUTH is no longer read. Set visibility: 'private' in the page config instead. If the status page still has that secret, the deploy stops and says how to remove it, so updating never opens a private page.
  • /admin and /events no longer redirect. Use /login and /history.
  • timeout on a monitor or a webhook must be a whole number of milliseconds from 1 to 60000. A longer one ran into the next check run. The config check names any monitor that breaks this. A webhook in the FLAREWATCH_WEBHOOKS secret with such a timeout still alerts, with the default timeout, and the Worker logs why.
  • Links in the config must be http(s) URLs or paths: a monitor’s link, links, poweredByUrl, logo and favicon. logo and favicon can also be data:image/ URLs.
  • The admin API rejects a maintenance whose monitors list holds anything but monitor ids. An empty list still covers every monitor.

Changed

  • A monitor that fails again within 15 minutes of recovering reopens the same incident instead of starting a new one. You still get a new down alert after the full grace period, and History shows one outage.
  • Each monitor keeps its newest 1,000 closed incidents.
  • An outage sends at most 5 error-change alerts.

Security

  • Only /embed pages can be shown in a frame on another site.
  • Admin API answers to scripts that sign in with the Basic header are no longer cacheable.
  • The sign-in and maintenance endpoints stop reading a request body at 4 KiB and 64 KiB.
  • Error answers from check proxies and webhooks, and Cloudflare’s trace answer, are read up to 4 KiB. The trace request has a timeout now.
  • A TCP check that times out closes its socket.
  • Webhook header values are masked in the logs.
  • Teams alerts no longer turn a monitor’s error text into links.

2.3.1

Security

  • Fixed an authorization bug in the status page’s admin API. Update your fork.

2.3.0

Added

  • The optional FLAREWATCH_WEBHOOKS secret holds alert webhooks as JSON, so their URLs and tokens stay out of your fork. See Alerts.

Fixed

  • /embed/<monitor> shows only the status card, without the page header and footer, and theme=light or theme=dark applies to the whole frame.

2.2.0

Added

  • dependsOn on a monitor lists the monitors it reaches its target through. While one of them is down, it sends no alert of its own, and that monitor’s alert names it under “Also down”. See Alerts.

Changed

  • FlareWatch keeps track of which outages it alerted about. A down alert that no webhook accepted is tried again on each check run, up to 10 times. A recovery alert only follows a down alert that went out, and a missed check at the end of gracePeriod no longer drops the alert.
  • A monitor that is still down when its maintenance window ends now alerts. It used to stay silent.
  • Outages already open when you upgrade stay silent, recovery included. After upgrading, check the status page for monitors that were down at the time.

2.1.0

Changed

  • Each row on the dashboard shows the monitor’s last 90 days, or the last 30 on a phone. Jobs show their recent runs. The row still opens the monitor’s page.
  • Colors are stricter. The uptime badge turns amber below 99.9% and red below 99%, where it used to stay green down to 99%. A day turns red after about 15 minutes down, not 12 hours.

2.0.0

Breaking changes

  • Monitor state lives in a Durable Object instead of KV, and every check run is saved, so latency charts get a sample every minute. The first start after the upgrade copies your 1.x history across, leaves the 1.x keys in KV in place, and adds an imported_to_hub key to show the copy happened. Remove kvWriteCooldownMinutes from worker.ts, or the build fails.
  • A check that crashes now opens an incident instead of only counting as down.
  • FLAREWATCH_STATUS_PAGE_BASIC_AUTH is gone. Set visibility: 'private' in the page config instead. Visitors then get the sign-in page, and the dashboard, History, monitor pages, badges, embeds and the JSON API are closed to them. While the old secret is still set on the Worker, the page stays private-only, so upgrading never opens a private page.
  • The /admin page is gone. Sign in at /login (/admin redirects there). Once signed in, the same pages show private monitors, and you add and edit maintenance windows on History.
  • The Events page is now History, at /history. Old /events links redirect there.
  • Config lives only in packages/config. The CONFIG_KV binding is no longer read, and neither is STATE_KV as a second name for FLAREWATCH_STATE. CI checks the config, so an invalid one fails before it deploys.
  • Everyone signed in with the password signs in once more after the upgrade. A password session now ends when FLAREWATCH_ADMIN_BASIC_AUTH changes.
  • Password sign-in needs the LOGIN_RATE_LIMIT binding from wrangler.jsonc, and refuses to run without it.
  • A monitor name links to its target without the credentials or query string. Set link to a full URL if you need them.
  • responseKeyword and responseForbiddenKeyword look at the first 1 MiB of a response only.

Added

  • Heartbeat monitors for jobs that report in, like backups, cron scripts and CI pipelines. One goes down when a ping is late or the job reports a failure.
  • Private monitors, checked and alerted as usual but shown only to people signed in.
  • A page per monitor, with its 90-day history, a 12-hour latency chart and its incidents.
  • Sign in with any OpenID Connect provider or GitHub, set in packages/config/src/access.ts. Besides operators, you can let in members, who see private monitors but change nothing, and audiences, who see certain page groups.
  • Sign-in attempts are limited per IP by a rate-limit binding, so failed logins no longer use KV writes.

Fixed

  • Slack, Discord, Zulip and Google Chat alerts no longer let text from a monitored site ping everyone or add links.
  • A failing check proxy shows as Proxy HTTP <status> on the page. Its response body goes to the Worker log, with the proxy token taken out.
  • Webhook errors in the Worker log no longer quote the webhook URL.
  • An oversized answer from a monitored site, GlobalPing or a check proxy fails that one check instead of the whole run.

1.1.0

  • GlobalPing TCP_PING monitors on port 443 no longer fail with a missing port error.
  • The shipped demo groups its monitors.
  • Documented that monitoring a site in the same Cloudflare zone needs a check proxy.
  • Dependencies updated, including TypeScript 7, Cloudflare workers-types 5, and jsdom 30.
  • Wrangler stays at 4.108.0 and @cloudflare/vite-plugin is pinned to 1.43.2. Newer versions crash the local dev server on Linux, which breaks the browser tests.
  • Renovate config for automated dependency updates.

1.0.0

First tagged release.

  • Wrangler-owned Cloudflare deploys replace the older Pulumi-owned production deployment model.
  • ntfy notification channel, alongside Slack, Discord, Telegram, and custom webhooks.
  • Self-deploy setup now requires only two GitHub Actions secrets: CLOUDFLARE_ACCOUNT_ID and CLOUDFLARE_API_TOKEN.
  • The deploy workflow creates or adopts the shared flarewatch-state KV namespace, injects it into both Worker configs, and deploys with Wrangler.