Troubleshoot missing phone alerts, Topic creation and replies

Use one non-sensitive test message and note its time, App/CLI versions and visible error code. Avoid a burst of resends. Separate service acceptance, device receipt and the displayed system alert.

When the message is in the Inbox, check alert settings first and keep the current Topic and identity. After changing a setting, send one new test and note its time and whether the app was backgrounded. Foreground synchronization does not prove that APNs/FCM push succeeded.

1. Check Ntfyx system notification permission and the banner, sound and lock-screen options you want.
2. Check mute and daily quiet hours inside this Topic, then system Focus/Do Not Disturb. Quiet hours pause alerts while messages and replies continue.
3. Open Ntfyx online to synchronize, then background it for a new test. Unlock after restarting. An iPhone before first unlock or a timed-out notification extension may show only a generic encrypted-message alert.
4. On Android, check Google Play services, connectivity to Google and the Ntfyx notification channel. Reopen after force-stop. Notification listeners/forwarders can remove alerts; blanket disabling of battery protections is not required.
5. If it still fails, report the time and the specific observation “received in phone, no system alert.” Do not include push tokens, message bodies or sending URLs.

Open and refresh the matching Topic. Public Topic owners receive directly; other readers must confirm the follow after preview. Reading the webpage does not subscribe the phone. Check whether the follow is paused/unsubscribed or a local block hides the source. For protected messages, match the sender’s local alias with the Topic authorized on the phone.

A newly authorized browser lacking old history is expected.

1. For a public send, use public read to match the accepted message id; this establishes cloud readability only. Public content lasts 24 hours, so an empty feed after expiry does not prove earlier rejection.
2. For protected CLI messages, run ntfyx topics and ntfyx doctor as the original paired user. Do not copy another user’s credentials to repair a connection.
3. Check connectivity and the original service environment. If one foreground refresh still leaves it missing, retain acceptance time and redacted errors for support; renaming, guessing IDs or repeated creation cannot recover it.

ntfyx public read --topic TOPIC_ID --limit 20 --json

• Public creation versus following

As of 2026-10-29, confirmed public releases are iOS 1.8.3 and Android 1.8.2. Update from your store, then use the public Topic or private connection entry on your phone. Android background push requires Google Play services.

1. Check the installed version first. Update from the store if you are on 1.8.1; a backend update cannot restore its missing button.
2. On iPhone 1.8.3 or later, enter a name or link in the public Topic entry, preview the existing or new Topic and confirm. Android 1.8.2 offers separate public creation, existing public-link subscription and private scanning entries; its subscription field needs a real link or ID.
3. For agent answers, choose private scanning and a protected Topic. Public Topics cannot accept signed answers.
4. After a submitted operation with an unknown result, refresh the original Inbox and resume that operation. Preserve its identity and app data instead of starting a replacement. If it remains stuck, record the version and error code and contact support.

• Current downloads
• Step-by-step phone setup for agents

Use the actual error and phone plan usage; do not treat every failure as “no free Topics left.” Topic count is not a paid tier. Free/Plus/Pro include 100/1,000/20,000 messages per UTC day, with separate Call and question sublimits. Already accepted answers can still finish. A paired CLI can inspect usage; anonymous public senders need the owner to check.

ntfyx usage --json

• Plans and counting rules

A saved phone reply is not an execution receipt. Check whether the original terminal/Agent is still running, then inspect the original request ID. The Source may be offline or revoked, its wait may have ended, or an external operation may have an unknown outcome.

1. Use result from the original paired user and CLI environment to inspect the original request. This is a read-only observation; do not add --claim just to test.
2. pending means unfinished; answered requires reading the verified decision. Preserve Deny instead of silently replacing the question to seek Allow.
3. expired/cancelled/replaced means the original request ended. A phone draft or late answer cannot revive it.
4. For a claimed answer or unknown execution outcome, inspect the original task log and target system. One-time claim cannot guarantee exactly-once external effects; do not automatically rerun them.

ntfyx result REQUEST_ID --json

• Verified answers and one-time claims

Pairing codes expire after five minutes. Generate a fresh code on the trusted Source only after the original pairing is known expired or cancelled, and check that phone and Source use the same environment. Offline drafts require connectivity and a fresh state/deadline check before submission. A new browser has independent keys and cannot read earlier messages; “Earlier request updated” does not give it authority to answer an old question.

Do not edit a pairing URL or share its fragment.

If the ordered checks still fail, provide App/CLI version, OS, time and timezone, redacted error code and the last confirmed step: accepted, received in phone, no system alert or answer submitted. For a missing creation entry, give the installed version; do not report a pending build’s test result as your own phone result.

Preview any diagnostic report before sending it yourself. Exclude message bodies, answers, Topic links, full sending URLs, tokens, pairing codes, recovery packages and private keys.

• Support channel