Security & Scanning Policy

Every check UptimeHelm runs is passive: it reads what a public web server already returns to any ordinary visitor. Nothing is submitted, guessed, brute-forced, or bypassed.

• Uptime and availability: whether a monitored URL responds, its HTTP status code, and response time.
• TLS certificate expiry, read directly from the certificate presented during the TLS handshake.
• Domain registration expiry, looked up via public RDAP data for the domain.
• Security headers: Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, Referrer-Policy, and content-type protection headers.
• robots.txt and sitemap.xml presence, canonical URL, page title, meta description, and social preview tags.
• Redirect behavior, including whether HTTP forwards to HTTPS and how many hops a redirect chain takes.
• Visible framework or library version fingerprints, only when they are already exposed in response headers or markup.
• Change detection: whether the title, redirects, headers, robots.txt, sitemap.xml, or homepage size have changed since the last check.

Optional heartbeat monitors work the other way around: your own job or cron pings a unique URL on a schedule you set, and UptimeHelm alerts you if a ping is missed. UptimeHelm never scans anything to originate a heartbeat check.

• Checks use only HTTP GET or HEAD requests. UptimeHelm never sends POST, PUT, DELETE, or any request that submits data or changes state on a monitored site.
• Every request carries an identifying User-Agent (for example, "UptimeHelm/0.2 endpoint monitor") so it is distinguishable in your server logs.
• Requests time out after a bounded window, typically 7 to 12 seconds depending on the check, and a configurable 1 to 30 seconds for your own monitor checks.
• Redirect chains are followed for at most 5 hops; anything longer is treated as a failure rather than followed indefinitely.
• Response bodies are read only as needed and capped in size (up to 1 MB for a homepage scan, up to 256 KB when checking for specific page text), so a check can never be used to pull down an unbounded amount of data.

Adding a website to UptimeHelm does not require proving ownership up front - passive, safe checks begin immediately so you can see value right away. Verifying ownership unlocks account-level controls tied to that domain.

• To verify, you add a DNS TXT record at _uptimehelm.yourdomain.com with a unique token UptimeHelm generates for your site.
• Only someone who can edit DNS for a domain can complete this, which is the same proof-of-control model used by most hosting, email, and CDN providers.
• Verification does not grant UptimeHelm any access to your domain, DNS, or hosting account beyond reading that one TXT record to confirm it matches.

Because UptimeHelm fetches URLs on request (both for account owners and for the no-login public checker on the homepage), every outbound check is guarded against being pointed at internal infrastructure:

• Only http:// and https:// URLs on standard ports are accepted; credentials embedded in a URL and non-default ports are rejected outright.
• localhost and .local hostnames are rejected before any network request is made.
• The target hostname is resolved via DNS, and every resolved address (IPv4 and IPv6) is checked against private, loopback, link-local, carrier-grade NAT, documentation, and multicast/reserved ranges. Any match is refused.
• This same check runs again on every redirect hop, not just the initial URL, so a redirect cannot be used to reach an internal address after an initial public one passed.
• DNS lookups themselves are time-limited so a slow or unresponsive resolver cannot hang a check indefinitely.

• Scheduled monitoring runs at the interval you choose per monitor - every 5, 15, or 60 minutes - and never more often than that, regardless of how many monitors or sites you have.
• The manual "Run check now" action is limited to once per minute, per site.
• The no-login public website checker on the homepage is limited to 8 checks per minute from the same IP address (30 if UptimeHelm cannot determine the caller's IP), after which it returns an HTTP 429 response until the window resets.

• Check results, incident history, and scan snapshots (headers, titles, redirect counts, and similar) are stored so they can power your uptime history, alerts, and public status page.
• Notification destinations (webhook URLs or alert email addresses) are only ever what you explicitly configure for your own sites.
• Account identity (name, email, avatar link) comes from Google or GitHub sign-in and is managed by Supabase Auth. UptimeHelm keeps a copy of those three fields so teammates on a shared site can see who is who, visible only to people who share a site with you. It does not receive or store your OAuth password or provider credentials.
• Status-page subscriber emails are opt-in, confirmed by email before any alerts are sent, and can be removed with a one-click unsubscribe link included in every email.
• Data for a site is retained for as long as that site remains in your account; deleting a site removes its checks, incidents, scan history, and notification routes along with it.
• UptimeHelm does not sell monitoring or account data, and does not share it with third parties for advertising. Processing is limited to the infrastructure providers needed to run the service: Supabase (database, authentication, and scheduled functions), GitHub Actions and GitHub Pages (scheduled checks and hosting), and Resend (delivering alert and confirmation emails).
• An AI-assisted review feature is planned to work with an API key you provide yourself and to analyze only the same passive evidence described above. It is not active in the current version of UptimeHelm, and no data is sent to an AI provider today.

• No vulnerability scanning, port scanning, fuzzing, injection testing, or any other active exploitation technique.
• No login attempts, credential testing, or attempts to access non-public pages, admin panels, or authenticated areas.
• No requests that submit data, change state, or otherwise modify anything on a checked site - only GET and HEAD.
• No scanning of internal, private, or link-local network addresses, enforced by the SSRF protections above, not merely requested.
• No checks against a domain without either an account owner adding it, or a person voluntarily entering it into the public, no-login checker.
• No selling or advertising use of monitoring or account data.

If you believe you have found a security issue with UptimeHelm itself, please email support@uptimehelm.com with details. Please do not test findings against sites you do not own or have permission to test.