AppHealthMeter bot

What this traffic is

AppHealthMeter is an uptime monitoring service. Our users add the addresses of their own websites and APIs, and we check those addresses at a fixed interval and alert them when something stops working. If you see our User-Agent in your logs, someone added this address as a monitor — usually the owner of the site or the team that maintains it.

• One address, one request. A check requests exactly the URL that was configured. We do not crawl, follow links, or discover other pages.
• No content is stored. We record the HTTP status code, the response time and an error message (e.g. “Timeout”). The response body is discarded.
• No request body. Even for POST or PUT monitors we send an empty request — the method is only used to see how your endpoint answers.

How to recognise it

Every HTTP check identifies itself with this exact User-Agent header:

AppHealthMeter/1.0 (+https://apphealthmeter.com/bot)

• Method: HEAD or GET by default; the monitor owner may choose POST, PUT, PATCH, DELETE, OPTIONS or QUERY.
• Frequency: one request per monitor per interval. The shortest interval is 30 seconds (paid plans); the Free plan checks at most every 5 minutes.
• Timeouts: 5 seconds to connect, then up to 60 seconds for the response (default 30 s). Redirects are followed for at most 5 hops.
• SSL certificate monitors open a TLS connection to host:port to read the certificate expiry date — no HTTP request is sent. Domain monitors query the registry (RDAP), not your server. Heartbeats are traffic from your systems to ours, never the other way round.
• Source: today all checks come from a single region in the European Union (Germany).

robots.txt

Our checks do not read robots.txt. We want to be upfront about this rather than claim otherwise. The Robots Exclusion Standard is addressed to crawlers that discover and index content. An uptime check discovers nothing: it requests one address, at the request of that site’s owner, and throws the response away. In practice it is the same as the owner running curl from a cron job on their own site.

If the requests are unwanted, the steps below — a server-side block or a message to us — are the right tools; a Disallow rule in robots.txt will not change anything.

How to limit or block it

Talk to whoever set it up

In most cases the monitor was created by your own team, a contractor or a client, and the simplest fix is asking them to pause it, delete it or lengthen the interval. Note that blocking our requests makes the monitor report “Down” to its owner — they will notice quickly and can then remove it.

Block by User-Agent

Any web server, CDN or WAF can reject the User-Agent. Matching on AppHealthMeter is enough.

# nginx
if ($http_user_agent ~* "AppHealthMeter") {
    return 403;
}

# Apache (.htaccess)
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} AppHealthMeter [NC]
RewriteRule .* - [F]

For a managed firewall (Cloudflare, AWS WAF and similar) create a rule that blocks requests whose User-Agent contains AppHealthMeter.

Reporting abuse and contact

If you are not the owner of the address, have not authorised the monitoring, or the frequency is causing problems, write to support@apphealthmeter.com. Please include the URL(s), timestamps with a time zone, and one log line showing the User-Agent. We identify the account, stop the checks and tell the user why. We reply on the same business day.

• Checks can never target private addresses (localhost, internal networks, cloud metadata endpoints), so our service cannot be used to probe your internal infrastructure.
• Security vulnerabilities in AppHealthMeter itself: see /.well-known/security.txt.