# FAQ

Source: https://www.pingtower.com/docs/help/faq/

Short answers. Each one links to the page with the long one.

## General

<details open><summary>Is Pingtower free?</summary>

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](/docs/service/plans/) and [pricing](/pricing/).
</details>
<details><summary>Do I need to install anything?</summary>

The iOS app, if you want a phone to ring. 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.
</details>
<details><summary>Is there an Android app?</summary>

In development. Webhook, Slack and Telegram integrations work today regardless of phone. See the [roadmap](/roadmap/).
</details>
<details><summary>Can one account be in several companies?</summary>

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.
</details>
<details><summary>Does it do uptime checks?</summary>

Not the service itself. Outside-in HTTP, TCP, DNS, certificate and ping checks are the [addons agent's](/docs/addons/) job; its measurements arrive as events and your rules threshold them. Nothing alerts on silence: a source that stops sending produces no alert.
</details>

## Alerts and paging

<details><summary>Why did I get paged three times for one problem?</summary>

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.
</details>
<details><summary>Why did an alert wake me through Do Not Disturb?</summary>

Because it opened, or escalated. Those two are the pages that mean "something is wrong right now", and they are delivered as [critical alerts](/docs/ios/critical/) 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.
</details>
<details><summary>I turned off Critical Alerts for Pingtower. What happens?</summary>

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.
</details>
<details><summary>Why did I only get a normal notification?</summary>

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.
</details>
<details><summary>I removed someone from the team. Are they still paged?</summary>

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 revoke a pairing. On a hosted team the membership is the whole answer and removal stops both.
</details>
<details><summary>What is the difference between ack and resolve?</summary>

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.
</details>
<details><summary>Why is the log tail behind my alert empty?</summary>

Usually because it is correctly empty. Retention is opt-in per source (`retain_logs`), so a source that was never told to keep its lines 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.
</details>
<details><summary>Two similar lines opened two alerts. Why?</summary>

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](/docs/service/logtail/).
</details>
<details><summary>Can I page a specific person rather than everyone?</summary>

Yes, with an escalation rung that names accounts or an [on-call schedule](/docs/service/oncall/). The first notification goes to every member; each rung narrows to who it names.
</details>
<details><summary>Can I ack from the lock screen?</summary>

Not yet. Ack and resolve are swipe actions in the app.
</details>

## Plans and quotas

<details><summary>Is the alert quota a monthly allowance?</summary>

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.
</details>
<details><summary>What happens at the cap?</summary>

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.
</details>
<details><summary>Are log lines counted the same way?</summary>

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.
</details>
<details><summary>Free or Pro — what actually changes?</summary>

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.
</details>

## Self-hosting

<details><summary>If I run my own daemon, why do I still need pingtower.com?</summary>

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](/docs/self-hosting/).
</details>
<details><summary>What does pingtower.com see from a paired box?</summary>

The pairing itself, and for each relayed page the alert event with its triggering line, kept only as a short-lived deduplication row. Sources, log lines, rules and alert history never leave the box. If you never pair, nothing is sent.
</details>
<details><summary>What does pingtower.com hold for a self-hosted team, exactly?</summary>

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.
</details>
<details><summary>Can I run it on a Raspberry Pi?</summary>

Yes. The daemon is a single static binary with SQLite inside it and ships for linux/arm64. It needs no external database.
</details>
<details><summary>How do I back it up?</summary>

Copy the data directory, or point `-backup-dir` somewhere and let the daemon write periodic SQLite backups. Restore is putting the directory back.
</details>

## Addons

<details><summary>Why does <code>sshcheck</code> refuse to start?</summary>

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.
</details>
<details><summary>Why is <code>icmpping</code> failing with a permission error rather than reporting down?</summary>

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`.
</details>
<details><summary>How do I get paged only when a target is down from more than one location?</summary>

Run the check from several agents and use `fire_after` with `distinct_sources: true` on the rule. See [Down from more than one place](/docs/addons/#down-from-more-than-one-place).
</details>
<details><summary>Can the tower make an agent run a command?</summary>

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.
</details>
<details><summary>Will you run the probes for me?</summary>

Planned: hosted addons from several regions, so "down from everywhere" and "slow from one region" become different alerts with nothing for you to run. See the [roadmap](/roadmap/).
</details>

## Account and data

<details><summary>How do I delete my account?</summary>

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.
</details>
<details><summary>I forgot my password.</summary>

Today this is operator-mediated: the service sends no mail yet, so write to [support@pingtower.com](mailto:support@pingtower.com) 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. A self-service reset is planned; until it ships this is the route.
</details>
<details><summary>How long is data kept?</summary>

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](/privacy/) is the binding version.
</details>
<details><summary>Is there an audit log?</summary>

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](/docs/service/team/#audit-log).
</details>
