FlareWarden's requests to your site

Monitoring a customer set up

A FlareWarden customer asked to be told when a site or service goes down. Usually it is their own site; sometimes it is a provider they depend on, whose status page or API they want watched.

• A check is one request for the address the customer gave, every 30 seconds to every hour as they chose, from one of the cities of the region their monitor is in.
• When a check fails, other cities check the same address once to confirm it: 2 unless the customer chose more, at most 10.
• A content check, which watches for a change on a page, may first ask whether the page changed (a HEAD request or a conditional GET) before it reads it.
• A customer may also ask to diagnose their own site now: one request from each of the 17 cities at once, at most 10 times an hour for one site.
• A check follows at most 10 redirects and reads at most 10 MB of the answer.
• While the customer adds a site or sets up a check, FlareWarden may also read the home page, its stylesheet and web manifest, and the status pages of services it uses, to suggest what to monitor.

These requests send one of:

• FlareWarden-Monitor/1.0 (+https://flarewarden.com/probes) Uptime-Monitor/1.0
• FlareWarden-Monitor/1.0 (+https://flarewarden.com/probes) Uptime-Monitor-Content/1.0
• FlareWarden-Monitor/1.0 (+https://flarewarden.com/probes) Uptime-Monitor-Dependency/1.0
• FlareWarden-Monitor/1.0 (+https://flarewarden.com/probes)

The Uptime-Monitor name at the end is the User-Agent these checks sent before they named FlareWarden, kept so that allowlists written for it still match.

Public checks

Someone asked FlareWarden whether a site is reachable, or what it could monitor on it, without an account: through Is It Down, the site scans, or an AI assistant connected to FlareWarden's MCP server. FlareWarden requested the site to answer them. A public check runs only when someone asks and is never repeated on a schedule. What FlareWarden keeps of it is stored under the site's name, never with who asked.

A public check follows at most 5 redirects and reads at most 1 MB of the answer. It sends:

Public checks explains each kind, how often it can happen, what FlareWarden keeps, and how to stop public checks of your domain.

FlareWarden's status pages

FlareWarden publishes status pages for well-known services, showing whether each is up from FlareWarden's own checks beside what the service's status page says.

• Each service's site is checked every 30 minutes to every 6 hours, depending on how much the page is read, from 8 to 17 cities at once.
• Between those checks, the site is checked again when someone opens its page 30 minutes or more after the last check, or when the service's status page reports trouble. Across every service, that is at most 200 and 100 extra checks an hour.
• The service's own status page is read too. Where Outage Watch, which posts the incidents vendors report, follows a service, it reads that service's incident feed every 3 minutes.

These requests send:

What every request does

• It sends no cookies, and keeps none between checks.
• It requests the address it was given and the redirects that address answers with. It follows no other links, so it does not read robots.txt, the way a browser opening the page does not.
• It is never retried on the spot; a confirming check from another city is a request of its own. An answer that refuses automated requests, such as a 403 or a 429, is recorded as refused, never as your site being down. FlareWarden does not hold off for a Retry-After: the next check comes on its schedule, because a site that says "try later" while it is failing is the outage a customer asked to hear about.

Checking a request is FlareWarden's

Every probe is sent from the addresses below, one or two pairs per city, which do not change when FlareWarden's machines do. Reverse DNS for them names our hosting provider, Fly.io, not FlareWarden, so check a request's address against this list. A program can read it at /probes/ips.json (updated 2026-09-29). The sales outreach's requests are not sent from these addresses.

US East

EU West

Asia Pacific

Allowing FlareWarden through a firewall

If you monitor your own site with FlareWarden and a firewall or bot protection refuses its checks, allow requests whose User-Agent contains FlareWarden-Monitor, or the addresses above for your monitor's region. Probe IPs & Allowlisting walks through it.

Stopping or reporting requests

• Public checks of your domain stop once it is on FlareWarden's opt-out list: see Public checks.
• Monitoring a customer set up is not stopped by the opt-out list, because the customer asked for it. If a FlareWarden monitor is checking your site and you did not set it up, or it is causing you trouble, tell us which address it requests and when. We will look into it with the customer and stop it if it is misused.
• FlareWarden's status pages: if you run a service FlareWarden publishes a status page for and want its checks changed or stopped, tell us.
• Sales outreach: reply “stop” to the email, or tell us, and we will not contact you again.

Tell us through the contact form, which opens on the Abuse Report topic, or email support@flarewarden.com. Include the User-Agent, the address and the time of a request if you have them.

FlareWarden's sales outreach

FlareWarden sends sales emails to a small number of businesses it thinks could use it. That outreach makes two kinds of request that are not probes: they are not monitoring, and they are not sent from the addresses above. Each names FlareWarden and links our privacy policy.

• FlareWarden-ProspectCheck/1.0 (+https://flarewarden.com/privacy#outreach): before FlareWarden emails a company, it reads a few pages of the company's public website, a small number of times. Our privacy policy says what it reads, what it keeps and how to stop it.
• FlareWarden-FactCheck/1.0 (+https://flarewarden.com/privacy#outreach): FlareWarden regularly reads the published prices of the services it compares itself with, so that its emails state them correctly.