HTTP service monitoring: status, text and JSON phone alerts

My Monitor checks a public HTTP or HTTPS endpoint every hour and reports results to your phone. Require a successful status, specified text within the response or a JSON field value. Each service keeps its own conversation. With default failure-only notifications, failures alert you and healthy or recovered results stay silent.

1. Open Discover → My Monitor → Add monitor.
2. Enter a public HTTP or HTTPS URL and a name. For text or JSON, fetch the response preview before entering your expectation.
3. Test the rule, then enable the monitor. The first observation runs after setup; subsequent checks run every hour.

• Downloads and app availability

CLI 0.2.0 can manage the same My Monitor items as your phone. Open My Monitor in the app once, then authorize your paired Source. Your primary phone must approve the exact monitor read/write scope. The default grant lasts 24 hours; --expires accepts 5 minutes to 24 hours. It ends when it expires, you revoke it, the Source is disconnected, or phone/root authority changes.

Phone and root private keys stay on the phone. Only this authorization question and answer are explicitly disclosed to the service for verification; ordinary agent exchanges keep their existing encryption.

ntfyx monitor authorize
ntfyx monitor add --name "My service" --url https://example.com/health --dry-run
ntfyx monitor add --name "My service" --url https://example.com/health
ntfyx monitor list
ntfyx monitor show MONITOR_ID
ntfyx monitor update MONITOR_ID --json-field ok --equals true
ntfyx monitor test MONITOR_ID
ntfyx monitor pause MONITOR_ID
ntfyx monitor resume MONITOR_ID
ntfyx monitor revoke

Use a status check for a public website or health endpoint, an exact text check when a response must contain a readiness marker, or a JSON-field check when a successful HTTP response can still report an unhealthy application. Preview the response in the app before choosing the expected value.

A reachable server is not always a healthy service. Every rule requires a final HTTP status from 200 to 299. Content rules add a second expectation.

Each finalized check creates a result in the monitor’s fixed Session in the system My Monitor Topic. Only notify on failure is on by default: healthy and recovered results are recorded silently, while confirmed failures send an alert. Turn it off to receive an alert for every check. A first hourly failure gets one confirmation after 60 seconds; that confirmation completes the same round, not a second message.

Continuing failures are recorded and alert again at the next hourly check. Monitoring infrastructure errors are not proof that your service is down.

Monitor messages use English with 🎉 for successful checks and recovery, and ❌ for failures. The text distinguishes a successful check from recovery. Individual scheduled check outcomes stay on the service for at most seven days; the existing app detail view continues to show up to twenty recent results.

Each week with check activity produces one 📊 weekly summary in its own Session, due Monday at 00:00 UTC (08:00 in China), covering the previous UTC Monday–Sunday. It lists monitors checked, check attempts, successes, failures, completed-check success rate and average response time. Unfinished executor checks are listed separately and excluded from the success-rate denominator; confirmation requests count as checks.

This rate is not uptime. The first report states when collection began. The summary sends a notification even with Only notify on failure enabled, while respecting Topic mute, quiet hours, system notification permission and delivery limits. No app update or language detection is required. User names, rules and message content are not translated.

Free includes one monitor, Plus includes ten, and Unlimited includes one hundred. All use the same hourly schedule. Monitor allowance is separate from custom Topic and notification-subscription allowance. Paused monitors retain their monitor slot until deleted. A downgrade pauses items beyond the new allowance; an upgrade does not silently re-enable paused checks.

Deleting a monitor stops its future checks and per-monitor alerts while received Inbox history remains. A weekly summary can still include checks completed before deletion. Monitoring has a separate alert budget and ciphertext storage pool, retained for at most seven days; it does not consume ordinary HTTPS or Agent message capacity.

Use a public Internet HTTP or HTTPS URL on port 80 or 443. Private networks, local hosts, metadata addresses and embedded credentials are blocked. Redirects, DNS destinations, request time and response size are bounded. The first version does not send your cookies, custom authorization headers or login credentials.

Put secrets in neither the URL nor the expected text. This is not a browser session, private-network agent or full uptime SLA.

The service reads the URL, rule and response to decide whether the expectation is met. It stores configuration, scheduling and bounded result history; response bodies are not included in result history. An explicit setup preview shows at most 4,096 UTF-8 bytes as plain text and marks truncation; that sample stays in the editor temporarily and is not stored in history.

Alert messages are encrypted for authorized receivers after the hosted service creates them. CLI and agent messages continue to use device-side end-to-end encryption.

• Privacy and encryption boundaries
• Data processing and retention

From agent questions to weekly subscriptions and website alerts, start with a use case. See what reaches your phone, then follow the steps to connect.

• Explore all use cases

Yes. A paired CLI or local MCP client can add, update, test and pause the same My Monitor items after explicit phone approval. That revocable grant lasts up to 24 hours and is separate from webhook management. The phone remains the place to review what was authorized.

• CLI and MCP monitor commands
• Receive HTTP events instead of polling