HeathsUptime

Privacy statement · Effective 3 November 2026

What we collect.
Why we keep it.

This statement describes the information handled by the Heaths Uptime application and its checking probes. Contact uptime@heaths.net with privacy questions, access/correction requests or a complaint.

Account and configuration information

We store an account name, email address, a password hash when a password is used, verification state, account limits and service settings. If Google sign-in is enabled and used, we store the Google account identifier and the profile details needed to establish the account. Google also handles information under its own policies.

Monitor settings include target addresses and ports, expected status/content, intervals and timeouts, notification destinations and status-page preferences. Avoid embedding passwords, personal information or other unnecessary secrets in target URLs or keywords.

What checks collect

We record observations such as timestamps, success/failure, response time, HTTP status, resolved IP, certificate expiry, errors and incidents. Keyword checks inspect response content in memory, subject to a response-size limit. The application does not archive full response bodies as check history. Settings may themselves contain the keyword to look for.

Where processing happens

The main application and database run on HAL in Australia. Assigned remote checks also run on Dave in Singapore. Remote probes receive the target and checking parameters needed for assigned work; they do not receive the account database, account passwords or Google/mail credentials. Hosting, network and mail providers handle data needed to supply their services. Choosing a remote location means the relevant target/check parameters are processed there.

Operator access and public information

Authorised service administrators can manage accounts and investigate operation. A superadmin can view a selected account dashboard and perform account-scoped actions on its behalf; this mode is visibly marked and audited. Suspended or archived accounts can be inspected in read-only mode. Staff do not need an account owner’s password to use this access.

Monitors are private to their account unless the user enables a public status page and selects monitors for it. Public status pages show selected names and availability results, not private target settings or heartbeat URLs. Notification messages are sent to configured destinations when account actions or monitor events require them.

Cookies and server logs

The public explanation pages do not need an application login cookie. You can install this site as a web app. Its service worker handles connection failures without caching account pages or monitoring results; normal browser session cookies still apply. Signing in uses an essential session cookie for authentication and form protection. The Google tag G-SJCGDBK3X8 is included on all HTML pages. Analytics collection is enabled on the public information pages to understand visits and improve the service, and is disabled on account, authentication, administration, status and other private screens. Public requests with query parameters other than recognised campaign parameters are also excluded from collection. Google may use analytics cookies and process browser/device, usage and approximate location information, including processing outside Australia. Our pageview configuration removes query strings, fragments and referrers; private account screens use a generic workspace address and title in their configuration and are opted out of collection. We do not configure account emails, passwords, monitor names or private tokens as analytics fields. Google Signals and advertising personalisation are disabled in our tag configuration. Analytics behaviour and retention also depend on the Google Analytics property settings managed by the operator. Browser privacy controls or blockers may prevent collection. See Google’s privacy policy and Google’s Analytics opt-out browser add-on. Standard web/server/security logs may record IP addresses, request paths, timestamps and errors; private tokens in URLs can therefore appear in infrastructure logs.

Retention and archiving

The configured check and regional history retention is currently 30 days, with periodic housekeeping. Other records have different purposes: closed incidents and application audit records may be kept for approximately 400 days; open incidents, accounts, configuration and feedback may remain longer. Backups and infrastructure logs have separate operator/provider retention and are not erased by application housekeeping.

Archiving is not erasure. It flags the account as archived, blocks sign-in and stops its checking/alerts while retaining its data for possible restoration. To ask about deletion, access or correction, contact the operator. A privacy request is reviewed separately from the archive control.

Requests, corrections and complaints

Email uptime@heaths.net with enough detail to identify your account or the affected service and what you want reviewed. We may request evidence of account or service ownership before disclosing information or changing access. We will investigate and respond through the contact channel you provide. Please do not email account passwords or private heartbeat/reset tokens.

This page is updated when the service’s handling practices change. The published date above identifies this version.