Privacy Policy · Pingtower

Pingtower is an alerting service: your applications send structured logs to a Pingtower server, and Pingtower turns them into alerts that reach a person — usually through the Pingtower iOS app. This policy explains what data we handle across the three places Pingtower runs: the hosted service at pingtower.com, the self-hosted server, and the iOS app.

Who this covers

The hosted service — Pingtower operated by us, where your account, tenants, and (if you use hosted tenants) your log and alert data live on our infrastructure.
The self-hosted server — the same software running on your own machine. Its data stays with you, with the specific exceptions described below.
The iOS app — the client that receives alerts on your phone.
This website — a static site with no analytics, advertising, or tracking cookies.

Your Pingtower account

Everyone who uses the iOS app has an account on the hosted service — including self-hosters. That is a deliberate part of how Pingtower works: Apple push notifications for the Pingtower app can only be sent by us, so the registry of which phone belongs to which person has to live on our service.

For your account we store:

Email address and a password hash. The email is your login identifier. We use it only for account email: password-reset links, and — where email verification is on — links confirming a new or changed address. We never send marketing email.
Session tokens and API keys, stored as hashes, so you and your tools can authenticate.
Tenant memberships and invites — which teams you belong to and what role you hold.
Device push tokens — the identifiers Apple or Google assigns your phone, so alerts for your tenants can be delivered to it. Registering a device is what makes your phone pageable; removing it (or deleting the account) stops that. To prove a phone really receives its pushes, we send it a silent push with a one-time code that the app sends back; we keep only a hash of the code, which expires shortly, and record when the phone was verified.
Which app versions you use. When a Pingtower app (iOS, macOS or Android) uses your account, we record its kind and version number, with the first and last time we saw it, so we can tell when an old app needs updating. We record nothing else about the device: no device identifier and no IP address. Development builds are not recorded.

Data in hosted tenants

If your tenant runs on the hosted service, we store and process on your behalf:

Ingested log lines your applications POST to us, plus the message templates Pingtower extracts from them for deduplication.
Alert state and history — which alerts opened, escalated, were acknowledged, and by whom.
Configuration — sources, rules, escalation and re-notify settings, integrations.
Audit records of significant actions in the tenant.
Checks and their results — the addresses you ask Pingtower to check, each run’s outcome and timings, and any credentials a check needs, which are encrypted at rest and never shown back. For a browser check we also keep its script and encrypted environment variables, and, when a run fails, a screenshot and video of the pages the browser loaded, and a trace of them when the check has no environment variables.
Incidents and status pages — incident timelines and notes, and what you choose to publish. Anything you publish on a public status page or behind an incident’s share link is visible to anyone who has the address. Private status pages set a session cookie for signed-in members; public pages and their embeds set none.
Secret findings — when a log line looks like it carries a credential, we record which project, source and kind of pattern it matched, never the matched text. A value you block is stored only as a keyed hash and its length.
Issue-tracker tokens — the GitHub or GitLab token you connect for incidents, encrypted at rest.
Pingtower agent versions — when a Pingtower addons agent reports in for one of your sources, we record the agent’s version for that project and source, with the first and last time we saw it.

Log lines can contain anything your applications put in them, including personal data about your own users. For that content, you are the controller and we are a processor: we store it, match it against your rules, and deliver it in alerts, and we do not use it for anything else. Do not send us data you are not allowed to share with a processor.

Retained logs are subject to your tenant’s retention settings and plan limits. Deleting a tenant deletes its data.

Self-hosting: what stays on your box, and what doesn’t

A self-hosted Pingtower server keeps the entire inbound half on your infrastructure: ingested logs, templates, rules, alert state, escalation, and outbound integrations such as webhooks, Slack, and Telegram. We have no access to any of it, and this policy does not govern it — you are the operator.

Two things still touch our service:

Pairing. To have alerts from your box ring a phone, each person links their account on your box to their pingtower.com account. We store that pairing record — which hosted account is pageable for which tenant on which box. Revoking the pairing stops the pages.
The relay. When your box pages someone, it sends the alert event — which includes the alert’s content, such as the triggering log line — to pingtower.com, along with the list of accounts on your box allowed to receive it, which we use only to choose recipients; we forward the event to Apple for push delivery to those people only. Relayed events are used only for delivery and deduplication; short-lived delivery bookkeeping (which events we have already pushed) is kept so retries don’t page you twice. We also record the Pingtower version your box reports when it uses the relay, with the first and last time we saw it.

If you never enable pairing or the relay, a self-hosted Pingtower sends us nothing.

AI assistants (the MCP connector)

You can connect an AI assistant — such as Claude or ChatGPT — to a hosted tenant, so you can ask it what is firing, whether an alert has fired before, or who is on call. Nothing is connected unless a member of the team does it. The connector is available for hosted tenants only; a self-hosted server’s data cannot be reached this way.

How a connection is made. You start it from the assistant. It sends you to pingtower.com, where you sign in, choose one team, and approve the permissions it may use. The consent page shows which app is asking, where it will send you back to, and which account you are signed in as. The assistant then receives an access token for that one team and those permissions only.

What the assistant can read, depending on the permissions you approve:

Alerts — each alert’s project, rule, state, severity, counts and times, and its latest log message, message template and extracted values.
Configuration — projects, alert rules, and the host or URL each check watches. Check credentials, request headers and request bodies are never returned.
On-call — who is on call now for each schedule, including your teammates’ email addresses.
Raw log lines — the most recent retained log lines. This permission is off unless you tick it, because log lines are the data most likely to contain your own users’ personal data.

The connector reads by default. It can change something only if the member who connects it grants a permission that allows it and an owner or admin has turned that on for the team: suggesting incidents and adding notes, acknowledging and resolving alerts, muting a rule or scheduling maintenance within the next 24 hours, and creating or editing checks. It can never delete anything, and every change is recorded in the team’s audit log under the member who connected it (or, for an API key, the member the key belongs to). Before log text leaves our servers we replace recognisable secrets — passwords, API keys, bearer tokens and similar — with [redacted]. This is best effort: a secret in a shape we do not recognise will pass through.

Who receives the data. What the assistant reads is sent to the company that runs it (for example Anthropic or OpenAI), at your direction, in the same way as an integration you configure. That company’s own privacy terms govern what it does with the data, including how long it keeps it. Log text is written by the systems you monitor, and anyone who can make those systems log a line can put instructions in it aimed at the assistant; an assistant that also has other tools connected (web access, email, chat) could be talked into sending what it read elsewhere. Connect assistants you trust, and leave raw log lines off unless you need them.

What we store. For each connection: which account made it, for which team, with which app and permissions, and when it was created and last used. Access and refresh tokens are stored as hashes. Access tokens last one hour; refresh tokens last thirty days and are replaced on every use.

How a connection ends. You can disconnect any of your connections under Settings → Connected apps. Team owners see and can disconnect every member’s connections, admins those of every member who is not an owner, and any other role allowed to manage members those of the members it outranks. A member limited to certain projects sees and can disconnect only their own, whatever their role. Owners and admins can also switch AI connectors off for the whole team, which stops every connection immediately. A connection also ends when you leave the team, change or reset your password, or delete your account; after ninety days without use; and one year after you approved it, whatever its use.

The iOS app

The app stores your credentials on the device (using the system keychain) and registers your device push token with the hosted service, as described above. Alert content — log lines, rule names, service names — is delivered to the app in push notifications, which transit Apple’s push infrastructure (APNs), and in API responses from the server your app is connected to. Critical alerts, which sound through Silent mode, use the same path.

The app contains no third-party analytics or advertising SDKs.

Who else receives data

Apple — push notifications, including their alert content, are delivered through APNs. Apple’s own privacy terms apply to its handling of push traffic.
Google — push notifications to the Android app, including their alert content, are delivered through Firebase Cloud Messaging.
Integrations you configure — if you point a tenant at a webhook, Slack, Telegram or Discord, alert data goes to that service at your direction. Choose endpoints you trust.
GitHub or GitLab, if you connect them — an incident’s title and link, and the cause and fix you write when you resolve it, go to the repository you chose. Internal notes and log lines never do; a public repository gets only the title and link.
Let’s Encrypt — a custom domain you add to a status page is sent to Let’s Encrypt to issue its certificate, and like every publicly trusted certificate it appears in public Certificate Transparency logs.
AI assistants you connect — if a team member connects an assistant such as Claude or ChatGPT, the data it reads goes to the company that runs it, at that member’s direction (see AI assistants above).
Our infrastructure providers — the hosted service runs on third-party servers, which process data on our behalf.
Our email delivery provider — account email (password-reset and verification links) is sent through a third-party email delivery service, which receives your email address and the message on our behalf.

We do not sell data, share it with advertisers, or use your logs or alerts for anything other than running the service.

Retention and deletion

Ingested logs: per your tenant’s retention settings and plan.
Alert history, configuration, audit records, incidents: for the life of the tenant.
Check results: detailed history for 8 days and hourly summaries for about a year; browser check runs for 30 days, and a failed run’s screenshot, video and trace for at most 7 days.
Alert timing used for response-time reports: one year.
Account data, sessions, device tokens, pairings: until you remove them or delete your account.
Relay delivery bookkeeping: short-lived, kept only long enough to deduplicate retries.
Version records (apps, agents, self-hosted servers): deleted once a version has not been seen for a year, and sooner when you delete your account (app versions) or the tenant is deleted (agent and self-hosted box versions).
AI assistant connections: until disconnected, or ended as described in AI assistants above; expired tokens are deleted automatically.

You can ask us to delete your account and its data at any time. Tenant data belongs to the tenant; a tenant owner can delete the tenant.

Security

All traffic to the hosted service is encrypted in transit. Passwords, API keys, and session tokens are stored as hashes and compared in constant time; API keys are scoped to a single tenant. No system is perfectly secure, but the design goal throughout is that a credential grants exactly one tenant’s data and nothing more.

Changes

We will update this policy as the product evolves and note material changes here with a new “last updated” date.

Contact

Questions or deletion requests: reach us via the contact details on this site.