FAQ

Yes, during preview, with no credit card. The Free tier holds 5 projects, 1,000 alerts and 50,000 log rows per tenant. Paid plans will come later, announced well ahead, and early users get founder pricing. See Plans & quotas and pricing.

The iOS or Android app, if you want a phone to ring, or the Mac app for pages on your desktop. The service is hosted. The daemon and the addons agent are optional, for keeping data on your own hardware and for probing things from outside.

Yes, in beta, as a direct download from this site rather than Google Play. It runs on Android 8 or later and offers each new version when it’s published. Webhook, Slack, Telegram and Discord integrations work regardless of phone.

Yes, in beta, as a direct download from this site rather than the Mac App Store; it is notarized by Apple, so it opens like any other app. It lives in the menu bar and shows pages as desktop notifications: click one to open the alert in the web app, or acknowledge it from the notification. It runs on macOS 14 or later and offers each new version when it’s published.

Yes. An account can belong to any number of tenants, each with its own API key scoped to that tenant. The app switches between them from Account.

Yes, the basic ones. On pingtower.com the service checks your website (HTTP), certificate expiry (TLS), domain (DNS), a server (ping) and ports (TCP) from its own servers in multiple regions of the world, with nothing to install; add them in the web app or the iPhone app. A self-hosted tower doesn’t run hosted checks: there, and for anything deeper like host metrics, the addons agent does the checking and its measurements arrive as events for your rules to threshold. A source that stops sending altogether can page you too, with a source_silent rule.

Renotify. A firing, unacked alert re-pages every renotify_minutes. Ack it and the paging stops while the count keeps climbing. Set max_renotify on the rule to cap it.

Because it opened, or escalated. Those two are the pages that mean “something is wrong right now”, and they are delivered as critical alerts wherever your phone permits it. A bump, an ack and a resolve never are — a colleague fixing something is news, not an emergency. Three things all have to be true for a page to break through: Apple has granted the app the entitlement, you allowed Critical Alerts when the app asked, and the event qualifies. If one alert is too loud too often, the fix is the rule that fires too often, not the alert level.

Pages arrive as ordinary notifications, subject to Do Not Disturb and Focus like any other app’s. Nothing else changes and nobody is told — your team’s roster looks the same with you on it, so if you are the one on call, say so. iOS has one app-wide switch for this; there is no per-rule or per-alert setting, on purpose.

One of the three conditions above was not met, most often the permission: the app asks once, and a “Don’t Allow” then stays until you change it in iOS Settings → Pingtower → Notifications → Critical Alerts. Bumps, acks and resolves are always ordinary. If the phone is signed into more than one account, every one of its registrations has to allow critical alerts; one that declines makes the phone ordinary in every tenant.

No. An integration’s Send test event is always an ordinary notification, by design; only a real alert opening or escalating is critical. If your phone holds ordinary notifications back, with Deliver Quietly, a Scheduled Summary or a Focus, the test waits with them. A test that arrived at all proves the chain works. See Critical alerts.

On a self-hosted team, possibly yes. Removing them from the box stops their access to the data; revoking their pairing stops their pages. Neither implies the other, and doing only one leaves a state nobody wants. Account → Who gets paged lists everyone and lets an owner or admin, or any role with members:write, revoke a pairing. On a hosted team the membership is the whole answer and removal stops both. Either way, removal also takes the person out of on-call rotations, escalation rungs and live overrides, and disables the webhooks, integrations and actions they created or last pointed somewhere; the app lists what it changed. Removing an owner asks for your password.

Ack means “I am on it” and stops paging. Resolve means “it is fixed” and closes the alert. A resolved rule that matches again opens a fresh alert.

Usually because it is correctly empty. Retention is per source (retain_logs). A new source keeps its lines unless it was created with retain_logs: false, and a source that was told not to keep them keeps none. It is also skipped, silently, while the team is over its log quota. The alert itself is unaffected either way — retention decides whether the lines are kept for reading, not whether they are matched.

Their templates differed. Template extraction replaces only the values you passed as keys; a changing id or duration left in the message makes every value its own shape. Move it into keys, or match on the common part with template_contains. See Log tail & templates.

Yes, with an escalation rung that names accounts or an on-call schedule. The first notification goes to every member; each rung narrows to who it names.

Not yet. Ack and resolve are swipe actions in the app.

No. Nothing resets. max_alerts is the number of alert rows the team currently holds, in every state. Rows are freed only by pruning, which runs hourly and removes alerts that have been resolved for more than thirty days (the daemon’s --resolved-horizon-days). A firing or acked alert holds its row for as long as it stays that way, so a team sitting at the cap with a thousand unresolved alerts stays at the cap however long it waits. Resolve what is done, or raise the plan.

Ingest answers 429 storage quota exceeded — but only when a line would open a new alert. Lines that bump an alert you already have still land. So a team at the cap keeps updating the alerts it knows about and quietly stops learning about new ones, and the 429 goes to whatever is posting the logs, not to anyone looking at the app. Watch Account → Plan & usage; the bar turns red near the ceiling.

Separately. Retained lines are kept for --retain-days (seven by default) and capped per source at ten thousand, oldest pruned first; the plan’s max_logs caps the team. Over the cap, retention is skipped rather than refused — the alert still opens, the tail behind it just stops growing.

Per-team ceilings only: alerts, retained log rows, projects, and the ingest and read rates. A plan is a property of a team, not of an account — one account can own a Free team and a Pro team. Separately, an account may own at most two teams (memberships in other people’s teams are not counted); raising that is something we do for you, not a plan feature.

For two things: your account, and the push to the App Store app. Apple only accepts a push from the team that owns the bundle id, so your box asks pingtower.com to forward the page. Alert data stays on your box. See the hosting model.

The pairing itself, and for each relayed page the alert event with its triggering line, kept only as a short-lived deduplication row, plus the list of box accounts allowed to hear it, used only to choose who gets the push. Sources, log lines, rules and alert history never leave the box. If you never pair, nothing is sent.

Your account, the team’s memberships, each member’s pairing to their box account, the phones’ device tokens, and the relay credential the box uses to ask for a page. Never the log lines. An owner can rotate the relay credential from Account → Who gets paged if it leaks.

Yes. The daemon is a single static binary and ships for linux/arm64. Point it at a PostgreSQL server, or configure no database and it runs on SQLite with nothing else installed.

On PostgreSQL, back up the database the way you back up any PostgreSQL server. On SQLite, copy the data directory, or point -backup-dir somewhere and let the daemon write periodic backups; restore is putting the directory back.

It is privileged and off by default. Add it to agent.enable_addons. It also needs a readable key file and a known_hosts entry for the target; there is no password or host-key-bypass option. An sshcheck check must be in the agent’s local config: the agent refuses one that Pingtower assigns, and logs assignment rejected. One stored in Pingtower before Release 1 is no longer assigned and shows paused with the reason local_only: move it into the agent’s config.

On purpose. “We lack permission” and “the host is unreachable” are opposite conclusions. On Linux, add the addons group id to net.ipv4.ping_group_range.

Run the check from several agents and use fire_after with distinct_sources: true on the rule. See Down from more than one place.

No. There is no such route. Checks are configured in the agent’s own file, and an addon is a closed registry entry with typed parameters, never a shell string.

For most checks, yes. On pingtower.com, hosted checks (HTTP, TLS, DNS, ping, TCP, gRPC, WebSocket, domain expiry, multi-step API checks and Playwright browser checks) run from Pingtower’s own servers in multiple regions of the world. When one region sees a failure the others re-check at once, and by default most must agree before it pages, with nothing for you to run. UDP and mail-server checks and the deeper addons (SSH, traceroute, host sensors and the rest) still run on your own agents.

Account → Delete account in the app, or POST /v1/account/delete with your password. Refused while you are the last owner of a tenant; hand it over or delete the tenant first.

Today this is operator-mediated: the service sends no mail yet, so write to [email protected] from the account’s address and a human relays the reset token to you. On your own box, the token is written to the daemon’s log for its operator to hand over (-log-reset-tokens, on by default). A self-service reset is planned; until it ships this is the route.

Retained log rows for the plan’s cap and the daemon’s -retain-days, seven by default. Resolved alerts for thirty days. Configuration, open alerts and audit records for the life of the tenant. Deleting a tenant deletes its data. The privacy policy is the binding version.

Yes, per tenant: every key minted or revoked, member invited or removed, rule changed, alert acked or resolved. Account → Audit log, or GET /v1/tenants/{tid}/audit. See Team & account.