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. Your plan sets how far back the app shows results: 30 days on Free, one year on Pro and Team. 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. Your plan sets how far back incident lists reach: 30 days on Free, one year on Pro and Team; older incidents are not deleted, only hidden from the lists. |
| 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 in Ireland (AWS eu-west-1), inside the EEA. That includes your email address, your monitors, your incidents, and your encrypted integration keys.
- 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.
Your account data and your check results are both stored inside the EEA. Data leaves it only when a vendor outside Europe processes it — Vercel serving the app, Sentry receiving error reports, Google Analytics on the marketing site, Resend’s US staff with administrative access to alert mail — or when a probe in Ashburn, San Jose, or Tokyo checks your monitor. Where that is a transfer out of the EEA or the UK, we rely on our vendors’ standard contractual clauses. 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.
With your consent, PostHog may also record a replay of your session inside the app: which pages you opened and where you clicked, so that a confusing screen can be found and fixed. The recording is masked in your browser before it is sent. Everything you type into any field is replaced with placeholder characters, and so is the text of your own configuration — monitor names and addresses, notification targets, status page copy, and the name and email shown in your account menu. Link targets, image sources and other element attributes are masked as well. Screens that handle integration keys are left out of the recording altogether. Recordings are deleted automatically after 30 days.
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 further measurements, Vercel Analytics and Vercel Speed Insights, tell us how fast pages load. They store nothing on your device and cannot identify you, so they are not part of the cookie choice. They do still see each visit, which is why they are switched off for visitors in the United Kingdom (see below).
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.
If you are visiting from the United Kingdom
If your connection appears to come from the United Kingdom, none of the measurement tools described above run for you, whatever you answer on the cookie banner. The Google Analytics script is not fetched, PostHog is not started — so there is no session replay and no product event — and the Vercel measurements are not loaded. The events our own servers record when an account is set up or a monitor is created stay in our own logs and are not sent to PostHog.
Your location is read once per page, from the country your network connection appears to come from, and is not stored. If it cannot be determined, we treat you as being outside the United Kingdom and the cookie choice above applies. Sentry error reporting still runs so that a crash you hit can be fixed, but the trail of clicks and page views it would normally attach to a report is left out for you, and its page-speed measurements are not collected.
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.
EU and UK representatives
Article 27 of the GDPR, and Article 27 of the UK GDPR, require a controller established outside those jurisdictions to designate a local representative and to name them where data subjects can find it. Below is where each one would be named, and where we say plainly when we have concluded that none is needed — together with the reason, so you can judge it rather than take it on trust.
- European Union (GDPR Article 27) — no representative is designated. GetPulseCheck is established in the European Union, and Article 27 applies only to controllers established outside it. Our processing falls under Article 3(1) directly. That is our own reading and it has not yet been confirmed by external counsel, so we state it as a position rather than a settled question. Either way you can write to getpulsecheck@gmail.com.
- United Kingdom (UK GDPR Article 27) — no representative is designated. We have no UK establishment and do not target the United Kingdom — no UK domain, pricing, or marketing — so Article 3(2)(a) does not apply. Article 3(2)(b) monitoring of behaviour was our residual risk through Google Analytics and PostHog; since #1628 we geo-scope visitors we detect as located in the United Kingdom out of every tool that could constitute monitoring, on top of consent. On our reading this keeps Article 3(2) from being engaged, but the detection is IP-based with known gaps and the underlying question remains unsettled, so no representative is required for now rather than settled for good. That is our own reading and it has not yet been confirmed by external counsel, so we state it as a position rather than a settled question. Either way you can write to getpulsecheck@gmail.com.
Part of the UK reading above is a technical measure, not just an argument: see “If you are visiting from the United Kingdom” for what we actually do about it.
Reaching a representative is never a precondition for exercising your rights. You can email us directly, and you can complain to your own supervisory authority — the data protection authority for your country in the EEA, or the Information Commissioner’s Office in the UK — without going through anyone.
Data processing agreements
If you need a data processing agreement — for example because you are a business customer 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.
Who we are, and how to reach us
The controller for the personal data described on this page is Amit Mande, trading as GetPulseCheck (enskild firma), at Sagogången 7 lgh 1201, 422 45 Hisings Backa, Sweden. GetPulseCheck is a sole trader business, so the controller is a person rather than a company.
Privacy questions, requests, and complaints go to getpulsecheck@gmail.com. You can also complain to your own supervisory authority — for Sweden that is Integritetsskyddsmyndigheten (IMY), and elsewhere in the EEA it is the data protection authority for your country.