Legal
Privacy Policy
Last updated
What we collect and why
Most of what we hold is data you typed in — the monitors you created — plus the results of checking them.
| Category | Examples | Why | How long |
|---|---|---|---|
| Account data | Email address, name if you provide one, password credentials held by Supabase | To sign you in and to tell you apart from other accounts | Until you ask us to close the account |
| Monitor configuration | Monitor names, target URLs and hostnames, check intervals, chosen regions | To run the checks you asked for | Deleting a monitor stops its checks and removes it from the app immediately, but the configuration row is marked deleted rather than erased, and is kept until the account closes. The copy held in the analytics database is deleted 400 days after it was last written. |
| Check results | Per-region status, response time, HTTP status code, error message, timestamp | To draw the charts, confirm outages across regions, and open incidents | Raw per-check rows are deleted automatically 400 days after they are recorded. The hourly and daily summaries built from them have no expiry and are kept until the account closes. The app itself charts at most the last 90 days. Ask us and we will delete your results sooner. |
| Incident history | When an incident opened and resolved, which regions confirmed it, who acknowledged it | To show what happened and to run escalation policies | Kept in the main database until the account closes. Nothing deletes incidents at a plan boundary today. |
| Integration credentials | PagerDuty routing keys, Slack tokens, webhook URLs | To deliver alerts where you told us to send them | Encrypted with AES-256-GCM. Disconnecting an integration marks the credential inactive and stops us using it, but does not erase the stored secret; ask us and we will delete it, and everything goes when the account closes. |
| Audit logs | Who created, changed, or deleted a monitor or an account setting, when, and the IP address and browser it came from | So you can see what changed in your own account, and so we can investigate abuse | Account and security events for 24 months, monitor configuration changes for 13 months, then deleted automatically. IP addresses are shortened to their network prefix after 90 days. |
| Usage and diagnostics | In-app product events, error reports, marketing-site page views | To find bugs and to understand which parts of the product get used | Per the vendor's default retention (see sub-processors) |
We do not sell personal data, and we do not use your monitor data to build advertising profiles.
Where your data is stored
The product deliberately spans several places, because the checks have to:
- Accounts and configuration live in a PostgreSQL database hosted by Supabase. That includes your email address, your monitors, your incidents, and your encrypted integration keys. We have not yet published which region Supabase runs that database in, so please treat it as possibly outside the EEA, and email us before you sign up if the answer matters to you.
- Check results live in a ClickHouse database we run on Hetzner hardware in Nuremberg, Germany. Raw per-check rows there are deleted automatically 400 days after they are recorded. The hourly and daily summaries built from them, and the record that a monitor was created or deleted, carry no expiry and are kept until the account closes.
- The probes run on Fly.io in Ashburn Virginia, San Jose, Stockholm, and Tokyo. Each probe holds your monitor’s target URL for as long as it takes to check it. This is unavoidable: a check from Tokyo has to happen in Tokyo.
- The app itself is served by Vercel from a global edge network, so requests you make are routed through infrastructure near you.
Data therefore moves between countries — at minimum between Germany, the United States, and the four probe regions. Where that involves a transfer out of the EEA or the UK, we rely on our vendors’ standard contractual clauses. Because we have not published the Supabase region, treat your account data as possibly stored outside the EEA rather than only passing through it. The full list is on the sub-processors page.
Legal basis (GDPR)
If the GDPR applies to you, we process personal data on these bases:
- Contract — running your account, your monitors, and your alerts. Without this we cannot provide the service.
- Legitimate interests — keeping the service secure, investigating abuse, and fixing bugs through error reports.
- Consent — anything you opt into separately: the analytics cookies described below, and connecting a third-party integration.
When you use GetPulseCheck to monitor systems that hold other people’s personal data, you are the controller of that data and we are your processor. See the section on data processing agreements below.
Analytics, cookies, and error reporting
We use two analytics tools, and neither of them runs until you say yes. Google Analytics measures traffic across the site. PostHog records product events inside the app — a monitor was created, a status page was saved — against your account ID. PostHog is hosted in the European Union.
On your first visit a banner asks whether we may switch them on. Declining is a single click, in the same place and at the same size as accepting. There is no pre-ticked box, and no extra screen you have to walk through to say no. Until you accept, the Google Analytics script is never fetched and PostHog is never started, so neither one writes a cookie or an identifier to your device. Google Consent Mode is set to deny analytics and advertising storage by default; the advertising signals stay denied even after you accept, because we do not advertise.
Your answer is stored on your own device — nowhere else — and it lasts until you change it. You can change it at any time from the Cookie preferences button in the footer, which reopens the same banner. It is in the footer of the marketing and sign-in pages, at the bottom of every page inside the app, and on public status pages, so withdrawing is one click from wherever you are.
When you withdraw, we stop sending straight away — Google Analytics is switched off through Google’s own opt-out flag, its script tags are removed from the page, and the cookies it had set are deleted; PostHog stops capturing and forgets the identity it had. One caveat, stated plainly: if Google Analytics had already loaded during that visit, its code stays in the browser’s memory, silenced, until you next load a page. Reloading clears it. PostHog identifies you by account ID alone; it no longer receives your email address or your name.
Two measurements are always on and are not part of that choice, because they store nothing on your device and cannot identify you: Vercel Analytics and Vercel Speed Insights, which tell us how fast pages load.
We use Sentry for error reporting. It is configured not to send personal data by default, and error events pass through a scrubbing step before they leave the app. Error reporting exists so that a crash you hit can be diagnosed and fixed, which is a different purpose from measuring usage, so it is not covered by the analytics choice above.
What you make public
Status pages and shared incident links are public by design. Anything you put on one — monitor names, incident notes — can be read by anyone with the link, and may be indexed by search engines. Nothing else in your account is public.
Security
Every query is scoped to your tenant, and account actions are written to an audit log. Integration credentials such as PagerDuty routing keys are encrypted with AES-256-GCM before they are stored, and only a short non-sensitive preview is kept in readable form. Connections between the app, the probes, and both databases use TLS.
Audit entries record the IP address and browser the change came from, because an audit log that cannot tell you where a change came from does not answer the question it exists for. That data does not stay forever. Account and security events are deleted after 24 months, monitor configuration changes after 13 months, and a scheduled job enforces both — the periods are not advisory. After 90 days we also shorten the stored IP address to its network prefix, dropping the last block for IPv4 and the interface identifier for IPv6, so an aged log still shows which network an action came from without continuing to hold the address it came from.
No system is perfectly secure. If you find a vulnerability, report it to getpulsecheck@gmail.com rather than disclosing it publicly, and we will work with you on a fix.
Your rights
Depending on where you live, you may have the right to access, correct, export, or delete your personal data, to object to or restrict processing, and to complain to a supervisory authority.
You can edit or delete monitors yourself from the dashboard. For anything else — a copy of your data, correction, or closing your account and deleting what we hold — email getpulsecheck@gmail.com and we will action it within 30 days. There is no self-service account-deletion button yet; a request by email is currently the way to do it, and we will confirm when it is done.
Deleting a monitor removes it from the dashboard immediately and stops its checks. What happens to the data behind it is less than a full erasure, and more than this page used to promise. The monitor’s row in our main database is marked deleted rather than erased, and stays until the account closes. Its raw recorded check results are deleted automatically, 400 days after each result was recorded — before September 2026 this page said no such automatic deletion existed, which understated what we do. The hourly and daily summaries built from those results are not deleted on any schedule.
To have a deleted monitor’s configuration row, its summarised history, or its raw results erased sooner than that, email getpulsecheck@gmail.com and we will delete them.
One caveat on any deletion: we take backups of the analytics database, and a backup written before your request still contains what it contained when it was written. Backups are not searched or restored to serve a deletion, and they expire on their own schedule, so a copy can outlive the deletion by that window.
Data processing agreements
If you need a data processing agreement — for example because you are an EU or UK business and GetPulseCheck processes personal data on your behalf — email getpulsecheck@gmail.com and we will put one in place. The sub-processor list forms part of it.
Changes to this policy
We will update this page when the product changes. For material changes we will email account holders, and the “last updated” date above will change.
Contact
Privacy questions, requests, and complaints go to getpulsecheck@gmail.com.