Privacy Policy

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 do not operate a mail server, so we never send marketing email; be aware this also means we currently cannot send password-reset 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 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.

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.

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, and we forward it to Apple for push delivery. 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.

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

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.
  • Integrations you configure — if you point a tenant at a webhook, Slack, or Telegram, alert data goes to that service at your direction. Choose endpoints you trust.
  • Our infrastructure providers — the hosted service runs on third-party servers, which process data 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: for the life of the tenant.
  • 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.

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.