# Pocket Alert

> Push notification service for developers and DevOps engineers, with a free plan (50 notifications/day). Send push notifications to iOS and Android via API or webhooks. Consolidate alerts from monitoring tools, deploys, and custom services into one mobile app.

## Product

- Web app: https://pocketalert.app
- Pricing: https://pocketalert.app/pricing
- iOS: https://apps.apple.com/us/app/pocket-alert/id6446805143
- Android: https://play.google.com/store/apps/details?id=com.pocketalert.app
- API docs: https://info.pocketalert.app/getting-started.html
- CLI: https://pocketalert.app/tools/cli
- Status page: https://status.pocketalert.app

## Pricing (USD / month)

- Free: 50 messages/day, 1 device, 1 webhook, 1 application
- Starter: $6 — 1000 messages/day, 3 devices, 5 webhooks, 5 applications
- Medium: $12 — 5000 messages/day, 5 devices, 20 webhooks, 20 applications
- Large: $25 — higher limits

Yearly billing offers a discount. See https://pocketalert.app/pricing.

## Key features

- REST API for sending push notifications: one authenticated POST to https://api.pocketalert.app/v1/messages (JSON or form-data) with title, message, optional application_id, device_id, level
- Priority levels per message: silent (-2), low (-1), default (0), high (1), critical (2). Critical bypasses Do Not Disturb on Android; high/critical arrive as time-sensitive on iPhone (break through Focus). Default level can be set per application and per webhook. Free plan delivers critical as high
- Webhook receivers (no-code): each webhook gets a unique receive URL; incoming JSON is mapped to the notification with GJSON placeholders (%field.path%); payloads may include a "level" field
- Message history, read/unread state, and per-day delivery stats
- Image attachments on paid plans
- Messages encrypted at rest (AES-256-GCM, per-user key)
- MCP server at https://mcp.pocketalert.app/mcp (tools include create_message, list_messages, get_message_stats) for Claude, Cursor, and other AI agents
- Native mobile apps for iOS and Android with per-application channels and priority filtering
- Web interface for notification management
- Free tools: CLI, Chrome extension, cron expression editor, webhook tester

## Integrations

Any service that can send an HTTP request or webhook works. Setup guides exist for GitHub, GitHub Actions, Bitbucket, Grafana, Datadog, Prometheus Alertmanager, UptimeRobot, Stripe, Zapier, Make.com, n8n, TradingView, Home Assistant, Lemon Squeezy, OpenClaw, and custom webhooks.

## Use cases

- Hub: https://pocketalert.app/use-cases
- Server monitoring: https://pocketalert.app/use-cases/server-monitoring
- Webhook to phone: https://pocketalert.app/use-cases/webhook-notifications
- Critical alerts & priority levels: https://pocketalert.app/use-cases/critical-alerts
- Cron job failures: https://pocketalert.app/use-cases/cron-job-alerts
- Backup success/failure: https://pocketalert.app/use-cases/backup-alerts
- Deployments & CI/CD: https://pocketalert.app/use-cases/deployment-alerts
- Website uptime & downtime: https://pocketalert.app/use-cases/uptime-monitoring
- Stripe & payments: https://pocketalert.app/use-cases/payment-alerts
- Send push via API: https://pocketalert.app/use-cases/api-alerts
- Send push with curl / from terminal: https://pocketalert.app/use-cases/curl-push-notifications
- Send links & notes from computer to phone: https://pocketalert.app/use-cases/send-links-to-phone
- Background jobs & workers: https://pocketalert.app/use-cases/background-job-alerts
- CPU, RAM & disk usage: https://pocketalert.app/use-cases/resource-usage-alerts
- SSL certificate expiration: https://pocketalert.app/use-cases/ssl-expiration-alerts
- New user signups: https://pocketalert.app/use-cases/signup-alerts
- Automations (Zapier/Make/n8n/IFTTT): https://pocketalert.app/use-cases/automation-alerts
- Homelab & self-hosted services: https://pocketalert.app/use-cases/homelab-alerts
- Frigate NVR & security cameras: https://pocketalert.app/use-cases/frigate-nvr-alerts
- Error tracking (Sentry & co): https://pocketalert.app/use-cases/error-tracking-alerts
- Database health & slow queries: https://pocketalert.app/use-cases/database-alerts
- Log monitoring: https://pocketalert.app/use-cases/log-monitoring-alerts
- E-commerce orders: https://pocketalert.app/use-cases/ecommerce-order-alerts
- Form submissions: https://pocketalert.app/use-cases/form-submission-alerts
- Security & SSH logins: https://pocketalert.app/use-cases/security-alerts
- AI agents (MCP): https://pocketalert.app/use-cases/ai-agent-alerts
- Kubernetes: https://pocketalert.app/use-cases/kubernetes-alerts
- IoT & sensors (ESP32, Home Assistant): https://pocketalert.app/use-cases/iot-sensor-alerts
- TradingView & trading bots: https://pocketalert.app/use-cases/tradingview-alerts
- Queue monitoring: https://pocketalert.app/use-cases/queue-monitoring-alerts
- Grafana alerts: https://pocketalert.app/use-cases/grafana-alerts
- Datadog alerts: https://pocketalert.app/use-cases/datadog-alerts
- GitHub Actions: https://pocketalert.app/use-cases/github-actions-alerts
- Zapier notifications: https://pocketalert.app/use-cases/zapier-notifications

## Comparisons

- Hub: https://pocketalert.app/alternatives
- Pushover alternative: https://pocketalert.app/alternatives/pushover
- ntfy alternative: https://pocketalert.app/alternatives/ntfy
- Pushbullet alternative: https://pocketalert.app/alternatives/pushbullet
- Simplepush alternative: https://pocketalert.app/alternatives/simplepush
- WebhookBeam alternative: https://pocketalert.app/alternatives/webhookbeam

## Blog

- Index: https://pocketalert.app/blog
- Latest posts cover integration guides (GitHub, Bitbucket, Grafana, Pulsetic, Make.com), webhook setup, and release notes

## Legal

- Terms: https://pocketalert.app/terms
- Privacy: https://pocketalert.app/privacy
- EULA: https://pocketalert.app/eula
- Refund policy: https://pocketalert.app/refund-policy

## Company

- Pocket Alert
- Djure Jaksica 1, floor 2, 11000 Belgrade, Serbia
- X: https://x.com/pocket_alert
- Bluesky: https://bsky.app/profile/pocketalert.bsky.social
- Threads: https://www.threads.com/@pocketalert
- Instagram: https://www.instagram.com/pocketalert/
- Mastodon: https://mastodon.social/@pocketalert
- LinkedIn: https://www.linkedin.com/company/pocket-alert/

---

## Use cases (full text)

### Know the second when a server goes down.
URL: https://pocketalert.app/use-cases/server-monitoring
Pocket Alert turns server monitoring alerts into push notifications on your iPhone or Android. Connect Grafana, Prometheus, UptimeRobot, or a plain cron health check to one webhook URL — alerts reach your phone in under a second, with no agent on the box and no email digest to dig through.
**Three steps to your first server alert**
1. Set up Pocket Alert — Install the pocketalert CLI and run pocketalert auth YOUR_API_KEY, or create a webhook for forwarding.
2. Wire up monitoring — Add a cron health check, a Netdata custom_sender, or an Alertmanager webhook_config pointed at the receive URL.
3. Get paged — Trigger a test alert and your phone buzzes a moment later. Map fields to fine-tune the content.
**From metric spike to your phone**
- Works with your stack — Grafana, Prometheus, UptimeRobot, Datadog, and Zabbix reach your phone once they fire a webhook.
- Sub-second delivery — Push arrives in under a second, ahead of the first user complaint.
- Field mapping (GJSON) — Map JSON payload fields to the title and message. The alert name and severity carry through to the notification.
- Script or webhook — A cron health check or a forwarded Alertmanager alert both reach your phone the same way.
- Per-app channels — Give prod, staging, and homelab their own channels.
- No agent required — Pocket Alert consumes the webhooks your monitoring already produces, so the monitored box runs nothing extra.
**FAQ**
- How do server monitoring alerts work?
  Pocket Alert gives each application an incoming webhook URL. Point a monitoring tool such as Grafana, Prometheus Alertmanager, UptimeRobot, Datadog, or Zabbix at that URL, and the alerts it fires turn into push notifications on your phone within a second.
- Can I customize the alert content?
  Yes. Map fields from the incoming JSON with GJSON paths to set the notification title and message. An Alertmanager alert keeps its name, status, and severity all the way through.
- Which monitoring tools are supported?
  Any tool that fires an HTTP request on an alert works: Grafana, Prometheus Alertmanager, UptimeRobot, Datadog, Zabbix, Netdata, Uptime Kuma, and custom health-check scripts.
- How do I avoid alert fatigue?
  Send a push when a server drops and another when it recovers. Per-application channels separate prod, staging, and personal infra, so urgent alerts stay out of a noisy feed.
- Do I need to install an agent on my servers?
  There is no agent to install. Pocket Alert receives the webhooks your monitoring already sends, so nothing extra runs on the monitored server.
- Can a server-down alert break through Do Not Disturb at night?
  Yes. Send the alert with level: critical and it bypasses Do Not Disturb on Android and cuts through Focus on iPhone as a time-sensitive notification. Keep recovery messages at default — or silent — so only the outage itself makes noise. Levels go from silent (-2) to critical (2) and work in the API, in webhook payloads, and as a per-webhook default.
### Any webhook, on your phone, instantly.
URL: https://pocketalert.app/use-cases/webhook-notifications
Pocket Alert turns any HTTP webhook into a push notification on your iPhone or Android. Point Stripe, GitHub, n8n, or your own backend at your receive URL and the event lands on your phone in under a second — no middleware, no email digest.
**Three steps to your first webhook push**
1. Create a webhook — Create a webhook with a GJSON message template on the Webhooks page.
2. POST an event — Copy the receive URL and POST a JSON body to it from any service or curl.
3. Receive the push — Your phone buzzes. GJSON placeholders pull nested payload fields into the push.
**Webhooks that reach your phone**
- Plain HTTP, no SDK — One HTTP POST is all it takes. The payload becomes a push as soon as it lands.
- Connect anything — Stripe, GitHub, Sentry, Zapier, Make, n8n, IFTTT, and your own backend all speak webhooks. They all work here.
- Map any payload — GJSON placeholders in the message template pull values from nested JSON, so the push shows only what matters.
- Skip the middleware — Point the source service straight at your URL, or route through automation when you need to reshape the data.
- Scoped & secure — Each receive URL is scoped to one webhook and application, has an unguessable slug, and runs over HTTPS.
- Sub-second delivery — A received webhook reaches your iPhone or Android in under a second.
**FAQ**
- How does webhook to push work?
  You create a webhook in Pocket Alert with a message template, and you get an inbound receive URL like https://p4a.me/wh/1234abcd. Any service that sends an HTTP POST can hit it: Stripe, GitHub, Make, n8n, or your own backend. The payload renders into a push on your phone.
- Can I shape the notification from a custom payload?
  Yes. The message template uses GJSON placeholders such as %repository.name% or %head_commit.message% to pull values out of nested JSON, so a Stripe event or a GitHub payload renders the exact fields you care about.
- Which services can I connect?
  Anything that sends HTTP requests works: Stripe, GitHub, GitLab, Sentry, Zapier, Make.com, n8n, IFTTT, and your own scripts.
- Do I need Zapier or Make in between?
  Point the source service straight at your Pocket Alert webhook URL. If you need to transform the data first, you can still route it through Zapier or Make.
- Is the webhook URL secure?
  Each receive URL belongs to one webhook and one application, and its slug is unguessable. Traffic runs over HTTPS, and you can delete and recreate the webhook anytime from the Webhooks page.
- Can a webhook control how loud the notification is?
  Yes. Include a "level" field in the JSON the service posts — silent, low, default, high, or critical — and the push takes that priority. A critical webhook breaks through Do Not Disturb on Android and cuts through Focus on iPhone. You can also set a default_level on the webhook itself, so everything it forwards arrives at the right volume without touching the sender.
### Alerts that break through silent mode and DND.
URL: https://pocketalert.app/use-cases/critical-alerts
Pocket Alert gives every push notification a priority level from silent to critical. On Android, a critical alert bypasses Do Not Disturb and silent mode; on iPhone it breaks through Focus as a time-sensitive notification. You set it with a single field in the API call.
**Three steps to alerts that wake you**
1. Pick a level — silent for digests, high for warnings, critical for incidents that cannot wait until morning.
2. Send the message — Add "level":"critical" to the API call, the webhook payload, or set a default on the application.
3. It breaks through — Android bypasses DND and shows full screen. iPhone cuts through Focus. Silent stays silent.
**Priority levels that match the incident**
- Five levels, one field — silent, low, default, high, critical — one level field on any message, in the API, a webhook payload, or MCP.
- Breaks through DND on Android — Critical alerts on Android post to a dedicated channel that bypasses Do Not Disturb and can show full screen.
- Cuts through Focus on iPhone — High and critical messages arrive as time-sensitive notifications on iPhone, so they break through Focus modes.
- Silent when it should be — Level -2 delivers without sound or vibration. Success pings and digests stay on record without waking anyone.
- Defaults per app & webhook — Set default_level once per application or webhook. Every message inherits it; any message can override it.
- Priority-first feed — The mobile app filters and sorts the feed by priority, so critical incidents never drown in routine noise.
**FAQ**
- Can a push notification bypass silent mode and Do Not Disturb?
  On Android, yes. Send a message with level: critical and it posts to a dedicated notification channel that bypasses Do Not Disturb and shows full screen — grant the app Do Not Disturb access once in Settings. On iPhone, critical messages come through as time-sensitive notifications, which break through Focus modes; full critical-alert sound that overrides the mute switch is rolling out as Apple grants the entitlement.
- What priority levels does Pocket Alert support?
  Five: silent (-2), low (-1), default (0), high (1), and critical (2). The API accepts either the name or the number, and common aliases work too — min, normal, urgent, and max. Send it as level or priority; both are accepted.
- Can I set a default level per application or webhook?
  Set default_level on an application or a webhook and every message routed through it inherits that level. An explicit level on the message itself always wins. If nothing is set anywhere, the message goes out as default.
- Do critical alerts work on the Free plan?
  Critical delivery is a paid feature. On the Free plan a critical message is delivered at high priority — it still arrives instantly and stays at the top of your feed, it just does not override Do Not Disturb.
- Does a silent message get lost?
  No. A silent message (level -2) skips the sound and vibration entirely and lands quietly in the notification tray and your message history. Use it for success pings, digests, and anything you want on record without a buzz.
### The instant a cron job fails.
URL: https://pocketalert.app/use-cases/cron-job-alerts
Pocket Alert sends a push notification to your phone the moment a cron job fails. Chain one line onto any scheduled command with && or || — fire on failure, on success, or both, and the push arrives as the job exits, error output included.
**Three steps to cron failure alerts**
1. Get your URL or CLI — Copy the incoming webhook URL for your application, or install the Pocket Alert CLI.
2. Add one line — Chain a curl call or pocketalert send onto your cron line, with || for failures or && for success.
3. Get alerted — Run the job. If it fails, your phone buzzes with the title and error output you set.
**Never miss a failed job again**
- One line in crontab — Chain a push onto any cron line with && or ||. It is one curl call, with no daemon to babysit.
- Alert only on failure — With ||, the alert fires only when the command exits non-zero.
- Include the error — Pipe stderr or the exit code into the message, so the push arrives with the error already attached.
- Any scheduler — crontab, systemd timers, the Laravel scheduler, Sidekiq, and K8s CronJobs all work, because every one of them runs commands.
- Heartbeat on success — Send a heartbeat after a successful run. When it stops arriving, you know the job died quietly and can dig in.
- Instant on finish — The push lands as the job exits, hours before anyone tails the logs.
**FAQ**
- How do I get alerts from cron jobs?
  Chain a notification onto your cron command in the shell. `&&` fires after a successful run, `||` fires after a failure, and Pocket Alert sends the push notification when the job exits.
- Can I alert only on failure?
  Use `||` so the alert fires only when the command exits non-zero: `mybackup.sh || curl ...`. Broken jobs reach you while the rest stay quiet.
- Can I include the error output?
  Yes. Capture the exit code or output and drop it into the message body. The Pocket Alert CLI pipes stderr straight into the notification.
- Does this work beyond crontab?
  Any scheduler works: crontab, systemd timers, the Laravel scheduler, Rails or Sidekiq cron, Windows Task Scheduler, Kubernetes CronJobs. If it runs a command, you can chain an alert onto it.
- Can I detect a job that never ran?
  Send a completion ping with `&&` after every successful run. Once the ping stops arriving, you know the job stopped running, and no extra tooling is involved.
- Can a failed nightly job wake me up — and success pings stay silent?
  Add level=critical to the failure alert and it breaks through Do Not Disturb on Android and cuts through Focus on iPhone. For heartbeat pings, use level=silent — they land in your history without a sound, so the record is there but your phone stays quiet.
### The moment a backup breaks.
URL: https://pocketalert.app/use-cases/backup-alerts
Chain an alert onto pg_dump, rsync, restic, or any backup command. A failure pushes to your phone the moment it breaks, and a daily success ping confirms the rest still ran.
**Three steps to backup peace of mind**
1. Get the CLI or key — Install the Pocket Alert CLI and run pocketalert auth, or grab your API key for a plain curl call.
2. Wrap your backup — Chain pocketalert send onto your backup command: || for failures, && for success.
3. Sleep easy — Failures push the moment they break. Success pings prove the job still runs.
**Trust your backups again**
- Catch silent failures — A failed backup pushes to your phone right when it breaks, weeks before an empty restore would.
- Confirm it ran — A success ping on each run proves the job still works. When it stops arriving, you know it died.
- See the reason — Pipe stderr into the message. The alert then shows you why pg_dump, rsync, or restic failed.
- Any backup tool — pg_dump, mysqldump, rsync, restic, borg, and tar all trigger on their exit code.
- A channel that fits — Send failures and routine success pings to separate applications, so the urgent ones never hide behind the noise.
- One line to add — One line chained onto the backup script you already run. No agent, no dashboard, no maintenance window.
**FAQ**
- How do I get alerts when a backup fails?
  Chain a notification onto your backup command. With `||`, a failure sends a push notification to your phone right away, days before the restore that would have caught it.
- Can I confirm a backup actually ran?
  Yes, and that is where the real value sits. Send a success ping with `&&` on every run. When the daily "Backup OK" stops arriving, you know the job quietly stopped working.
- Can I see why the backup failed?
  Capture stderr and put it in the message. The CLI pipes the last lines of the error log into the alert, so you can see why pg_dump or rsync failed.
- Which backup tools are supported?
  Anything you script can trigger an alert on its exit code: pg_dump, mysqldump, rsync, restic, borg, Duplicati, tar jobs, and managed snapshot scripts.
- How do I keep success pings from being noisy?
  Send failures and success pings to different applications. Failures land in a channel you watch closely, while the daily "Backup OK" sits in a quiet one that stays auditable.
- Can a failed backup break through Do Not Disturb?
  Yes. Add `level=critical` to the failure branch and Android posts it on a channel that bypasses Do Not Disturb, while iPhone shows it as a time-sensitive notification that breaks through Focus. Send the daily "Backup OK" with `level=silent` and it lands in history without a sound.
### The instant a deploy finishes.
URL: https://pocketalert.app/use-cases/deployment-alerts
Add one notification step to GitHub Actions, GitLab CI, or Jenkins, or point a Vercel or Netlify deploy webhook at Pocket Alert. The deploy result reaches your phone within a second of the job finishing, with the commit, branch, and environment attached.
**Three steps to deploy alerts**
1. Get the key or webhook URL — Create an API key for a CLI or curl call, or a webhook and copy its receive URL.
2. Add a step or webhook — Add a notify step to your pipeline, or paste the receive URL into Vercel or Netlify deploy notifications.
3. Ship with confidence — Ship a release and your phone buzzes with the result, commit, and environment.
**Every release on your phone**
- Drops into any pipeline — GitHub Actions, GitLab CI, Jenkins, and CircleCI each need one step at the end of the pipeline.
- Success or failure — Send on success, on failure, or both. Run the notify step on if: failure() to hear only about broken releases.
- Deploy context — Put the commit, branch, environment, and run URL in the message so you know exactly what shipped.
- Per-environment channels — A separate app per environment keeps prod, staging, and preview deploys in their own channels.
- Instant on finish — The push lands when the job ends, so you can close the pipeline tab.
- Zero setup — One CLI call or curl in your job. There is no Slack bot to install.
**FAQ**
- How do I get deploy notifications?
  Add a notification step at the end of your pipeline in GitHub Actions, GitLab CI, Jenkins, or CircleCI. Run the Pocket Alert CLI or a curl call, and the deploy result arrives as a push notification as soon as the job ends.
- Can I alert only on failed deploys?
  Yes. Use the job status to send a success or failure message, and run the notify step only on if: failure() so a broken release is the alert you get.
- Can I include the commit and environment?
  Put the commit, branch, environment, and pipeline URL in the message body. The alert then tells you what shipped and where, and links straight to the run.
- Which CI/CD tools are supported?
  Anything that runs a command works: GitHub Actions, GitLab CI, Jenkins, CircleCI, Bitbucket Pipelines, or a plain deploy script. For Vercel and Netlify, create a Pocket Alert webhook and paste its receive URL into their deploy notification settings.
- Can I split prod and staging alerts?
  Create a separate application per environment for prod, staging, and preview. Production deploys then land in their own channel, and you can tell releases apart at a glance.
- Can a failed production deploy break through Do Not Disturb?
  Yes. Send failed deploys with level=critical: Android posts them on a dedicated channel that bypasses Do Not Disturb, and iPhone shows them as time-sensitive notifications that break through Focus. Routine success pings can go out with level=silent, so they sit in history without a buzz.
### The moment your site goes down.
URL: https://pocketalert.app/use-cases/uptime-monitoring
Pocket Alert turns uptime-monitor webhooks into push notifications on your phone. When UptimeRobot, Better Stack, Healthchecks.io, or Uptime Kuma sees your site go down, you know in under a second — and you get the recovery ping the moment it comes back.
**Three steps to uptime alerts**
1. Create your webhook — Create a webhook with a GJSON message template and copy its receive URL from the Webhooks page.
2. Wire up your monitor — Paste it as a webhook alert contact in UptimeRobot, Better Stack, Healthchecks.io, or Kuma.
3. Stay ahead of outages — Trigger a check failure. The down alert lands right away, and recovery follows once it passes.
**Catch downtime before your users do**
- Works with any monitor — Forward the webhook from UptimeRobot, Better Uptime, Pingdom, or Uptime Kuma and alerts start flowing.
- Down and recovery — Both the down alert and the all-clear land on your phone, so you know when it broke and when it returned.
- Status in the alert — Response time and status code travel inside the message. Triage before you open a laptop.
- Map their payload — A GJSON template maps the monitor name and status straight from your tool's own webhook payload.
- Per-site channels — A channel per site shows which service is down as soon as the push arrives.
- Faster than email — Push beats email by minutes. During downtime, those minutes cost users and revenue.
**FAQ**
- How do uptime alerts work?
  Point your uptime monitor at your Pocket Alert webhook URL. UptimeRobot, Better Uptime, Pingdom, and Uptime Kuma all work. A failed check pushes a down alert straight to your phone.
- Do I get a recovery notification too?
  Yes. Most monitors fire one webhook on down and another on up, so you get both the outage and the all-clear. Each carries the response time and status code.
- Which uptime monitors work?
  Anything that sends a webhook on a state change works: UptimeRobot, Better Uptime, Pingdom, Cronitor, Uptime Kuma, Healthchecks.io, and your own ping script.
- Can I monitor without a third-party tool?
  For a basic check, chain a curl onto a scheduled ping. For full coverage, run a dedicated monitor and forward its webhook to Pocket Alert.
- How do I make outages stand out?
  Use a separate application per site so you see which service is affected the moment the push arrives. Word the GJSON template so the status and host read clearly, and the down alert tells you everything before you open a laptop.
- Will a downtime alert wake me if my phone is on silent?
  Yes. Send the down alert with level critical and it bypasses Do Not Disturb on Android and cuts through Focus on iPhone as a time-sensitive notification. Keep the recovery ping at default or silent, so 3 AM only happens when the site is actually down.
### The moment a payment lands.
URL: https://pocketalert.app/use-cases/payment-alerts
Pocket Alert turns Stripe webhooks into push notifications on your phone. Every successful charge, failed payment, and cancellation lands in under a second, amount and customer included. Know about a failed payment before your customer emails you.
**Three steps to payment alerts**
1. Create the webhook — Create a Pocket Alert webhook with a GJSON template mapping the Stripe payload, then copy its receive URL.
2. Add a Stripe endpoint — Paste the receive URL into Stripe as an endpoint and subscribe to charge.succeeded, charge.failed, and the events you want.
3. See the sales — Make a test payment. The charge lands on your phone with the amount and customer email.
**Your revenue in real time**
- Works with any processor — Add your webhook URL as an endpoint in Stripe, PayPal, Paddle, or LemonSqueezy, then sales start coming through.
- Amount & customer — Map the amount, customer email, and event type so the push reads like an actual sale.
- Pick your events — Subscribe only to the events you want: successful charges, failed payments, and cancellations.
- Catch failures & churn — Create a webhook for charge.failed and one for customer.subscription.deleted, so dunning and churn each ring on their own channel.
- Real-time revenue — A cleared sale reaches you right away. No dashboard to refresh, no daily report to wait for.
- Direct & secure — Each webhook URL is scoped and stays secret over HTTPS, so you can point Stripe straight at it.
**FAQ**
- How do I get payment notifications?
  Create a webhook in Pocket Alert with a message template, then paste its receive URL into Stripe as an endpoint. Each Stripe event (charge.succeeded, charge.failed, customer.subscription.deleted) renders against your template and lands as a push.
- Can I show the amount and customer?
  Yes. Your GJSON template pulls fields straight from the Stripe payload — %data.object.amount% and %data.object.billing_details.email% — so the alert reads "New payment 4900 · alex@acme.com". Stripe amounts are in the smallest currency unit (cents).
- Can I pick which events to receive?
  Subscribe your Stripe endpoint to the events you want, such as charge.succeeded, charge.failed, and customer.subscription.deleted. Only those POST to your receive URL and reach your phone.
- Which payment providers are supported?
  Stripe, PayPal, Paddle, LemonSqueezy, Chargebee, and any processor that sends webhooks will work. Point its endpoint at your Pocket Alert receive URL and map its payload fields in the template.
- Can I separate failed payments from sales?
  Yes. Create one Pocket Alert webhook per event type — one for charge.failed, one for customer.subscription.deleted — and give each its own application so dunning and churn ring on a channel you can tell apart.
- Can failed payments ring louder than routine sales?
  Set a default level per webhook: keep routine sales at default, give the charge.failed webhook level high so it cuts through Focus on iPhone, and send churn events silent if you only want them on record. A critical level even breaks through Do Not Disturb on Android — useful when a failed payment means a production account just lost service.
### Send a push from your backend.
URL: https://pocketalert.app/use-cases/api-alerts
The Pocket Alert API sends a push notification to your phone with a single authenticated HTTP POST. Fire it from Node, Python, PHP, or Go — title, message, priority level — and it hits your iPhone or Android almost instantly.
**Three steps to your first API push**
1. Get an API key — Create an API key on the API Keys page and keep it in an environment variable.
2. Send a request — POST a JSON title and message to the messages endpoint with the key in the Token header.
3. Ship it — Your phone buzzes within a second. Add application and device targeting as your needs grow.
**Notifications, one request away**
- Plain REST, no SDK — One authenticated POST sends a push from the HTTP client you already use. No SDK, queue, or broker involved.
- Any language — Node, Python, PHP, Go, and Ruby can all fire a Pocket Alert notification.
- Key-based auth — Your API key rides in the Token header over HTTPS. Create, scope, and rotate keys on your own schedule.
- Full control — Route with application_id and target a single device_id, or omit it to reach every device, in one call.
- Sub-second delivery — Pushes reach your iPhone or Android in well under a second, quick enough to drive real-time backend alerts.
- CLI & webhook ready — The same API powers the CLI and webhooks. Start with code and layer in either one later.
**FAQ**
- How do I send a notification via API?
  POST to the Pocket Alert messages API with your key in the Token header and a JSON body holding the title and message. The notification lands on your phone right away.
- How does API authentication work?
  Authenticate with an API key from the Settings page, sent in the Token header over HTTPS. Create and rotate keys whenever you need, and scope alerts per application.
- Which languages are supported?
  Any language that makes an HTTP request works: Node, Python, PHP, Go, Ruby, and Rust. Nothing to install, just a plain REST call from the HTTP client you already use.
- What can I control in the request?
  Set the title and message, route to a specific application with application_id, target one device with device_id (or omit it to reach every device), and set the priority with level — from silent to critical. A critical message breaks through Do Not Disturb on Android and cuts through Focus on iPhone.
- Is there a CLI or webhook option too?
  Yes. The Pocket Alert CLI wraps the same API for scripts and CI. If you would rather skip code, create a webhook and point a service at its receive URL.
### Your phone, one curl away.
URL: https://pocketalert.app/use-cases/curl-push-notifications
Send a push notification to your phone with a single curl command: POST a title and a message to the Pocket Alert API with your key, and it lands on your iPhone or Android in under a second. Works from any shell, script, or box that has curl.
**Three steps from shell to pocket**
1. Get an API key — Sign up free, create a key on the API keys page, export it as an environment variable.
2. curl the API — POST title and message to /v1/messages with the Token header. Form-data or JSON.
3. Phone buzzes — The push arrives in under a second. Chain with && or || to alert on success or failure.
**The terminal-to-phone pipeline**
- One line, no SDK — POST title and message with an API key header. No SDK, no OAuth, no dependencies beyond curl itself.
- Built for shell scripts — Chain with && and || to push on success, failure, or both. Your crontab and CI scripts already know how.
- JSON or form fields — JSON or form-data — the API detects the content type, so the quick terminal version and the scripted version both work.
- Priority per message — Add level=critical to break through silent mode for real incidents, or level=silent for a quiet record that doesn't buzz.
- History included — Every push lands in your history with delivery stats, so a fired-and-forgotten script message is never actually lost.
- Works from any box — The same request works from a Raspberry Pi, a build server, a VPS, or WSL — anywhere curl runs, your phone is reachable.
**FAQ**
- What is the minimal curl command to send a push?
  curl -X POST 'https://api.pocketalert.app/v1/messages' -H 'Token: YOUR_API_KEY' -d 'title=Done' -d 'message=Build finished'. That is the whole thing — no SDK, no client library, no OAuth dance. Any machine with curl can send.
- Does the API take JSON or form fields?
  Both. The endpoint accepts application/json and form-data (-d key=value pairs), and detects which one you sent. Form-data is shorter to type in a terminal; JSON is easier to build programmatically.
- How do I get notified when a long-running command finishes?
  Append your command with &&: make build && curl … fires only on success. Use || for failure alerts, or ; to notify either way. For long jobs, capture the exit code and put it in the message so the push tells you what happened.
- Can I set the priority from the command line?
  Add -d 'level=critical' and the push bypasses Do Not Disturb on Android and cuts through Focus on iPhone. Use level=silent for pings you want on record without a sound. Five levels: silent, low, default, high, critical.
- Where does the API key come from?
  Create one on the API keys page after signing up. Put it in an environment variable or your secrets manager rather than hardcoding it in scripts. The Free plan includes 50 messages a day — enough for a busy day of scripts.
### That link belongs on your phone.
URL: https://pocketalert.app/use-cases/send-links-to-phone
Found something on your computer that you need on your phone? Push it. The Pocket Alert Chrome extension sends a link or a note from your browser toolbar to your iPhone or Android in one click — the link arrives tappable, and every note stays in a history synced across your devices.
**Three steps to your pocket**
1. Install & connect — Install the Chrome extension and paste an API key from your account into its settings.
2. Paste & send — Drop a link or note into the send form in your toolbar and pick a device — or all of them.
3. Tap it on your phone — The push lands in under a second. Tap the link on your phone and it opens in the browser.
**Computer to phone, without the self-email**
- One click from the toolbar — The send form lives in your browser toolbar. Paste, pick a device, send — drafts survive the popup closing.
- Links arrive tappable — URLs in the message are tappable on the phone and open straight in your browser.
- Pick a device or all — Send to the phone in your pocket or broadcast to every device on the account.
- Nothing gets lost — Every link and note stays in a history synced across phone, web dashboard, and extension.
- Silent notes via API — From the API or terminal, send with level silent — no sound, no vibration, just there in history.
- Terminal works too — Not in Chrome? One curl from any terminal or the CLI sends the same push.
**FAQ**
- How do I send a link from my computer to my phone?
  Install the Pocket Alert Chrome extension, paste the link or note into the send form in your toolbar, and pick a device — or broadcast to all of them. The push lands on your iPhone or Android in under a second, and the link in the message is tappable.
- Is it like a shared clipboard?
  Close, with one honest difference: nothing syncs automatically. You choose what to push — a link, an address, a code snippet, a note — and only that crosses over. Everything you send stays in a history that is synced across your phone, the web dashboard, and the extension.
- Can I send to just one device?
  Yes. The send form lets you target a single device or broadcast to every device on your account — useful when the link is for your personal phone, not the family tablet.
- Do links actually open on the phone?
  Yes. Open the message on your phone and any URL in it is a tappable link that opens straight in your browser. No copying character by character from a notification.
- What if I am not in Chrome?
  The extension runs in Chrome and Chromium browsers like Edge. Anywhere else, one curl does the same job — Linux terminal, a Firefox keyworded bookmark to the web dashboard, or the Pocket Alert CLI. Anything that can make an HTTP POST can send a note to your phone.
- Will every note buzz my phone?
  Notes sent from the extension arrive as regular notifications. When you send from a terminal or the API, add "level":"silent" and the note skips sound and vibration entirely — it just appears in your history for when you look. The free plan includes 50 messages a day, which is plenty of links.
### The instant a job throws.
URL: https://pocketalert.app/use-cases/background-job-alerts
Call Pocket Alert from your job's failure hook in Sidekiq, Celery, Laravel, or BullMQ. A thrown worker carries its job name, arguments, and exception to your phone, and a completion ping lands when critical jobs finish.
**Three steps to background job alerts**
1. Get the API key or CLI — Create an API key, or install the Pocket Alert CLI for shell-based workers.
2. Hook into failures — Call Pocket Alert from your queue framework's failure hook and pass the job name and error.
3. Catch dead workers — Trigger a failing job. Your phone buzzes with which worker died and why.
**Never miss a dead worker**
- Hooks into any queue — Sidekiq, Celery, Laravel, BullMQ, and Hangfire call Pocket Alert from a failure hook you already have.
- Alert on failure — Wire it into the death handler and only failed jobs reach you.
- Full failure context — Job class, arguments, and exception arrive in the message, so you can triage without opening your tracker.
- Confirm it ran — Ping on completion for critical jobs. A silent nightly import means it stopped running.
- A channel per worker — Give each worker its own application so a stuck queue lands in a channel you can spot at a glance.
- Instant on throw — A thrown worker pushes to your phone well before you would think to tail the logs.
**FAQ**
- How do I alert on failed background jobs?
  Call the Pocket Alert API or CLI from your job's failure handler or rescue block. A thrown worker sends a push notification to your phone with the job name and the error attached.
- Can I hook into my queue framework?
  Yes. Most queue frameworks expose a failure callback: Sidekiq death handlers, Celery task_failure, and Laravel failed(). Put the Pocket Alert call there and only genuine failures notify you.
- Can I include the job and error?
  Put the job class, arguments, and exception message in the body. The alert tells you which job died and why, which usually saves a trip to your error tracker.
- Which queue systems are supported?
  Sidekiq, Resque, Celery, RQ, Laravel queues, BullMQ, Hangfire, and Kubernetes Jobs all work through either a failure hook or a non-zero exit.
- Can I confirm a job actually ran?
  Send a completion notification on critical jobs. If a nightly import never pings, the worker probably stopped processing without raising anything.
- Can a dead worker alert override Do Not Disturb?
  Yes. Pass level=critical in the failure hook and Android routes the push through a channel that bypasses Do Not Disturb, while iPhone delivers it as a time-sensitive notification that breaks through Focus. Completion pings for routine jobs can use level=silent and stay in history without a sound.
### Before a disk fills up.
URL: https://pocketalert.app/use-cases/resource-usage-alerts
Run a small threshold check with df, free, or top, or forward an alert from Grafana or Netdata. When CPU, memory, or disk passes your limit, a push notification arrives on your phone carrying the current value.
**Three steps to resource alerts**
1. Get the CLI or URL — Install the Pocket Alert CLI, or grab your webhook URL for a curl-based check.
2. Set a threshold — Add a threshold check to cron, or forward an alert from your monitoring tool.
3. Act with runway — Usage passes the line and your phone buzzes with the value, while you still have runway.
**Warned before the box runs dry**
- One shell check — A two-line check with df, free, or top pushes when usage passes your limit. Nothing to install.
- Or your existing tools — Or forward threshold alerts from Grafana, Netdata, Zabbix, and Prometheus.
- Usage in the alert — The message carries the current value and threshold, so you know the urgency and the location.
- Early thresholds — Warn at 85% disk or 90% memory and the alert reaches you with time to act.
- Catch it early — A full disk or pegged CPU can drop services with no warning. This catches it while time remains.
- Instant warning — When a threshold trips, the push arrives. No dashboard to keep open.
**FAQ**
- How do I get resource usage alerts?
  Schedule a small check, or forward a threshold alert from Grafana, Netdata, or Zabbix that POSTs to Pocket Alert when CPU, memory, or disk passes a limit. The warning reaches your phone with time to react.
- Can I do this without a monitoring tool?
  Yes. A two-line shell check with df, free, or top compares usage against a threshold and pushes only when it trips. No monitoring platform needed.
- Can I see the actual usage?
  Put the current value and the threshold in the message, like "Disk 92% on /var". You learn how urgent it is and which mount or process caused it.
- Tooling or a plain script?
  Both work. Forward threshold alerts from Grafana, Netdata, Zabbix, or Prometheus, or run a tiny cron check on the box. Pocket Alert takes the push either way.
- How early should I be warned?
  Set the threshold below the danger zone, around 85% disk and 90% memory. That leaves enough time to clear space or scale up.
- Can a disk-full alert get through Do Not Disturb?
  Yes. Add level=critical to the check that must wake you, say a 95% disk threshold, and Android posts it on a channel that bypasses Do Not Disturb while iPhone shows it as a time-sensitive notification that breaks through Focus. Keep the early 85% warning at the default level so it stays polite.
### Days before a certificate expires.
URL: https://pocketalert.app/use-cases/ssl-expiration-alerts
A daily openssl and whois check flags any certificate or domain with fewer than N days left. The hostname and exact date arrive as a push notification on your phone at 30, 14, and 3 days out, with renewal time to spare.
**Three steps to expiry alerts**
1. Get the CLI or URL — Install the Pocket Alert CLI, or grab your webhook URL for a curl-based check.
2. Schedule the check — Add a daily openssl or whois check that fires as the deadline nears.
3. Renew in time — Warnings land at 30, 14, and 3 days out. You renew long before anything lapses.
**Renew before it lapses**
- SSL and domains — openssl handles the cert, whois handles the domain. One daily script watches both.
- One daily check — A short cron job covers it. No paid monitoring service.
- Which cert, what date — The hostname and exact expiry date land in the message, so you know which cert is on the clock.
- Staggered warnings — Stagger alerts at 30, 14, and 3 days. A failed auto-renew still leaves time for a manual fix.
- Avoid the outage — An expired cert throws browser warnings and costs you trust. This catches it days ahead.
- Runs anywhere — Run it from cron, systemd, or a scheduled GitHub Action.
**FAQ**
- How do I get SSL expiry alerts?
  A daily check reads the certificate expiry date and POSTs to Pocket Alert once fewer than N days remain. You hear about it with renewal time to spare, not at midnight when the cert is already dead.
- Can I check domains as well as SSL?
  Yes. openssl reads the cert expiry and whois reads the domain expiry. A short script compares either against a threshold and alerts you as the deadline approaches.
- Can I see which cert and when?
  Put the hostname and exact expiry date in the message. You know which certificate is lapsing and how many days are left to renew it.
- Where do I run the check?
  cron, a systemd timer, or a GitHub Actions schedule all work. Anywhere that runs a daily command and makes an HTTP request will do.
- How far ahead should it warn?
  Alert at 30, 14, and 3 days out. If an auto-renew fails, that last window still gives you time to renew by hand before the cert lapses.
- Can the last expiry warning break through Do Not Disturb?
  Yes, give it a level. Send the 30-day heads-up with level=silent so it sits in history without a sound, and mark the tighter warnings level=critical: Android posts those on a channel that bypasses Do Not Disturb, and iPhone shows them as time-sensitive notifications that break through Focus.
### The moment a new user signs up.
URL: https://pocketalert.app/use-cases/signup-alerts
Call Pocket Alert from your signup handler, right after the user record is created. Each registration reaches your phone with its email and plan, and the same line handles upgrades and milestones.
**Three steps to signup alerts**
1. Get your API key — Create an API key in your account, and store it as an env var on your backend.
2. Hook your signup — POST to https://api.pocketalert.app/v1/messages from your signup handler with the new user's email or plan.
3. Feel the growth — Register a test user. Your phone buzzes as they join.
**Watch your product grow, live**
- One line to add — One call in your signup handler turns each new user into a push. No analytics pipeline required.
- Who just joined — Email, source, and plan ride along in the message, so the alert names the person who joined.
- Milestones too — Point the same call at upgrades, first projects, and invites to follow activation, not just signups.
- Any stack — Wire it from your backend, a database trigger, or a no-code tool watching your auth provider.
- Real-time growth — Seeing the user count tick up keeps a founder going.
- Scales with you — As volume grows, trade per-signup pings for milestones or a digest and the channel stays useful.
**FAQ**
- How do I get signup notifications?
  POST to the Pocket Alert messages API from your signup handler, right after you create the user record. Send a title and message, and the alert lands on your phone carrying their email or plan.
- Can I include the user details?
  Yes. Put the email, source, or plan in the message and each alert reads "New Pro signup · alex@acme.com" with whatever detail you choose.
- Can I track milestones beyond signup?
  Point the same one-line call at any milestone: a first project, an upgrade, a first invite. Each fires its own push, so activation shows up next to registration.
- Does it work with my stack?
  It runs from any stack. Call it from your backend, from a database trigger via webhook, or from a no-code tool like Zapier watching your auth provider.
- Will this get noisy at scale?
  Early on, every signup deserves a ping. Once volume climbs, switch to milestones or a daily digest and the channel keeps its signal.
- Can a big signup ring louder than the rest?
  Yes. Every message takes a level, from silent (-2) to critical (2). Send level high when an enterprise plan signs up and it arrives as a time-sensitive push that breaks through iPhone Focus modes. Once you move to a daily digest, send it at silent — no sound or vibration, and it still shows in your history.
### Get a push when a workflow runs.
URL: https://pocketalert.app/use-cases/automation-alerts
Hear from your Make, n8n, or IFTTT workflows the moment they finish, and get a push the second one breaks without warning. No more silent automations you only notice when something downstream goes wrong.
**Three steps to automation alerts**
1. Get an API key — Create an API key on the API Keys page for the Token header.
2. Add a final step — Add a final HTTP step to your Make, n8n, or IFTTT workflow pointed at the messages API.
3. Close the loop — Run the workflow and your phone buzzes with the result. Wire up errors for failure alerts.
**Know when your workflows run**
- One final step — One final HTTP step in Make, n8n, or IFTTT turns the whole workflow into a push.
- Catch failures — Point error handlers and fallback paths at Pocket Alert and a broken scenario reaches your phone.
- Data from the run — Carry record names, customers, and totals from earlier steps into the alert so it describes the run.
- Any platform — Make, n8n, IFTTT, Zapier, and Pipedream each fire through a standard HTTP request module.
- Detect silent stops — Heartbeat on every run. When the pings stop, you learn the automation went quiet on its own.
- Result in hand — The result lands on your phone when the run ends, sparing you a trip to the run history.
**FAQ**
- How do I get automation notifications?
  Add a final HTTP step to your Make, n8n, or IFTTT workflow and POST it to https://api.pocketalert.app/v1/messages with your Token header. Each run sends a push notification, so you no longer dig through the run history.
- Can I alert when an automation fails?
  Use an error or fallback path. Make has error handler routes, n8n has an Error Trigger workflow, and IFTTT can branch on a filter. Point any of them at the messages API and failures land on your phone.
- Can I include data from the run?
  Yes. Pass any field from an earlier step into the message, such as a record name, customer, or total, and the alert tells you what the run actually did.
- Which automation tools work?
  Make, n8n, IFTTT, Zapier, and Pipedream all work through their HTTP request module pointed at the Pocket Alert messages API.
- Can I detect an automation that stopped?
  Send a heartbeat from each successful run of a scheduled scenario. If the pings stop, the automation has gone quiet without throwing an error, which is otherwise easy to miss.
- Can a failed run be louder than a routine one?
  Yes. Add a level field to the JSON body, from silent (-2) to critical (2). Give the error path level high so a broken workflow lands as a time-sensitive push that cuts through iPhone Focus, and send routine heartbeats at silent — they skip the sound and vibration but stay in your history.
### Know when something happens at home.
URL: https://pocketalert.app/use-cases/homelab-alerts
Watch your homelab from anywhere — Home Assistant, Uptime Kuma, or any self-hosted box can reach your phone without ever exposing a port. The free tier covers a personal lab.
**Three steps to homelab alerts**
1. Get the URL or CLI — Copy your application webhook URL, or install the Pocket Alert CLI on your box.
2. Wire up your boxes — Chain a curl onto a script, forward a webhook from Kuma or Home Assistant, or use systemd OnFailure.
3. Monitor from anywhere — Fire an event and your phone buzzes, even from behind NAT with no ports exposed.
**Monitoring for your homelab**
- Works with your stack — Uptime Kuma, Home Assistant, Proxmox, Pi-hole, and the *arr apps forward a webhook or chain a curl.
- No exposed ports — Outbound HTTPS only. No public IP needed, and it runs fine from behind NAT or a VPN.
- Per-machine channels — One app per machine keeps NAS, Proxmox, and Pi-hole alerts in their own channels.
- Scriptable anywhere — Call it from bash, a systemd unit, a Docker healthcheck, or a cron job.
- Free for hobby use — The free tier covers a personal homelab, with no per-seat pricing.
- Sub-second delivery — Delivery takes under a second, so a problem at home reaches you wherever you happen to be.
**FAQ**
- How do I alert from my homelab?
  Any self-hosted box that can make an HTTP request can reach you. Chain a curl onto a script, forward a webhook from Uptime Kuma or Home Assistant, or call the CLI from a systemd unit. The alert finds your phone no matter where the server runs.
- Does it work with self-hosted apps?
  Yes. Pocket Alert pairs with Uptime Kuma, Home Assistant, Proxmox hooks, Pi-hole, the *arr apps, and plain bash scripts. If it can POST JSON, it works.
- Do I need to expose my server?
  No public IP, no port-forwarding. Your server opens an outbound HTTPS request to Pocket Alert, which means it works from behind NAT, a home router, or a VPN.
- Can I separate my different machines?
  Create one application per box or service. Your NAS, Proxmox, and Pi-hole alerts each land in a separate channel and stay easy to tell apart.
- Is there a free option for hobby use?
  Yes. The free tier covers a personal homelab. No per-seat pricing, and no enterprise monitoring contract for the privilege of hearing about a sick NAS.
- Can an alert break through Do Not Disturb at night?
  Yes. Send it with level critical and on Android it posts to a dedicated notification channel that bypasses Do Not Disturb and can even show full screen — you grant DND access once. On iPhone, high and critical arrive as time-sensitive notifications that break through Focus modes, and the full critical sound that overrides the mute switch is rolling out as Apple grants the entitlement. On the free plan critical is delivered as high: still instant, without the DND override.
### Know when someone is on camera.
URL: https://pocketalert.app/use-cases/frigate-nvr-alerts
Frigate detects a person on the driveway and the alert lands on your phone in under a second. A Home Assistant automation or a Node-RED flow listens to Frigate’s MQTT events and makes one HTTP POST to Pocket Alert — filtered by label and score, and a night-time detection sent as critical can break through Do Not Disturb.
**Three steps to camera alerts**
1. Get a token or URL — Create an API key, or copy an application webhook URL for each camera.
2. Wire the bridge — Add a Home Assistant automation or Node-RED flow on the frigate/events MQTT topic.
3. Get the push — Walk past a camera and your phone buzzes in under a second, in that camera’s channel.
**Push alerts from Frigate without extra add-ons**
- Person, not leaves — Match label "person" with a score threshold in the automation. A swaying branch never wakes you.
- A channel per camera — One application per camera keeps the driveway, the porch, and the garage in separate channels.
- Critical when it matters — A night-time person detection sent as critical can bypass Do Not Disturb. Routine events stay silent.
- Footage stays home — Frigate stays fully local. Only the alert text you send leaves your network — never the footage.
- Works with your bridge — A Home Assistant automation or a Node-RED flow forwards the MQTT event with one HTTP POST.
- History of detections — Every forwarded detection lands in searchable history with stats — scroll what happened while you were out.
**FAQ**
- How do I get Frigate notifications on my phone?
  Frigate publishes every detection as an MQTT event. A Home Assistant automation (or a Node-RED flow) listens to the frigate/events topic and makes one HTTP POST to the Pocket Alert messages API with a title and a message. The push lands on your phone in under a second.
- Do I need Home Assistant?
  No. Anything that can subscribe to MQTT and make an HTTP POST works — Node-RED, a small Python script, or Home Assistant if you already run it. Frigate itself does not send notifications; it publishes events, and the bridge you choose forwards them.
- Can a person alert wake me at night?
  Send it with "level":"critical". Android delivers it on a dedicated channel that bypasses Do Not Disturb — you grant DND access once. On iPhone, high and critical arrive as time-sensitive notifications that break through Focus modes. On the free plan critical is delivered as high — still instant, without the DND override.
- How do I avoid a push for every motion event?
  Filter in the automation, not on your phone. Match only events with type "new" and label "person" (or "car"), and add a score threshold so a swaying branch never fires. Give each camera its own application, and send routine detections as level silent — they land in history without a sound.
- Does my camera footage stay local?
  Yes. Frigate keeps recording and detecting entirely on your own hardware. The only thing that leaves your network is the alert text you choose to send — a title like "Person on driveway" and a short message.
- Can I review past detections later?
  Every detection you forward sits in a searchable history in the app and the web dashboard, with per-application stats. Useful when you come home and want to scroll what the cameras saw while you were out — not just the last push.
### Make exceptions land on your phone.
URL: https://pocketalert.app/use-cases/error-tracking-alerts
When Sentry, Rollbar, or Bugsnag catches a new exception, the title and severity land on your phone in under a second. Catch the error before your users report it.
**Three steps to error alerts on your phone**
1. Create a webhook — Create a Pocket Alert webhook with a GJSON message template and copy its receive URL.
2. Wire up the tracker — Paste the URL into a Sentry Internal Integration (or Rollbar/Bugsnag webhook) and attach it to an alert rule.
3. Map and ship — GJSON maps data.event.title, culprit, level, and web_url into your push. The next exception buzzes your phone.
**From stack trace to lock screen**
- Works with every tracker — Sentry, Rollbar, Bugsnag, Honeybadger, and Airbrake all fire an outgoing webhook on a new issue. Point it at Pocket Alert and you are done.
- Map fields with GJSON — GJSON paths pull data.event.title, data.event.culprit, and data.event.level straight out of the payload into your notification.
- Level and rule inline — Show the error level and the rule that fired right in the push so a fatal exception reads differently from a warning.
- A channel per environment — Each application has its own webhook URL, so prod, staging, and a specific service stay in separate channels.
- Sub-second delivery — The exception hits your phone in under a second, well before the email digest goes out.
- Secret webhook URL — The webhook URL is your application secret over HTTPS. Rotate it whenever you need a fresh endpoint.
**FAQ**
- How do I get error alerts on my phone?
  In Sentry create an Internal Integration with a webhook URL set to your Pocket Alert receive URL and the Alert Rule Action enabled, then add it to an issue alert rule. When the rule fires, Sentry POSTs the issue and the push reaches your phone in under a second.
- How does field mapping work?
  Sentry issue-alert webhooks nest the data under data.event. Pocket Alert reads it with GJSON paths, so you map data.event.title to the notification title and data.event.culprit — or the web_url — into the body, and the push tells you exactly which issue fired.
- Can I show error level and the rule?
  The payload carries data.event.level (warning, error, fatal) and the rule name in data.triggered_rule. Reference both in your GJSON message template so a fatal exception reads differently from a warning.
- Can I separate prod and staging?
  Give each environment its own application. A prod webhook and a staging webhook land in separate channels, and you can mute staging without touching prod.
- Do I need to install an agent?
  Nothing. Pocket Alert just receives the webhook your tracker already sends, so there is no agent or SDK to install. Sentry, Rollbar, Bugsnag, Honeybadger, and Airbrake all support outgoing webhooks.
- Can a production exception break through Do Not Disturb?
  Yes. Add "level":"critical" to the message and on Android it posts to a dedicated notification channel that bypasses Do Not Disturb — you grant DND access once. On iPhone, high and critical arrive as time-sensitive notifications that break through Focus modes. Every message accepts a level from silent to critical, so a staging warning can stay quiet while a prod fatal wakes you. On the free plan critical is delivered as high: still instant, just without the DND override.
### Find out when your database stops answering.
URL: https://pocketalert.app/use-cases/database-alerts
A failed health check, a lagging replica, a disk creeping toward full. Your monitoring fires a webhook to Pocket Alert and the alert reaches your phone in under a second. Works with Postgres, MySQL, Redis, and MongoDB, and runs no agent on the database host.
**Three steps to database alerts on your phone**
1. Create a webhook or key — Create an API key for a cron script, or a webhook and copy its receive URL.
2. Point monitoring at it — Add the receive URL to Grafana, Alertmanager, pgwatch, or curl the messages API from a cron health check.
3. Get paged — A failed check fires the alert and your phone buzzes in under a second. Use separate webhooks for the primary and replicas.
**From the alert manager to your pocket**
- Every failure mode — Connection refused, replication lag past threshold, WAL piling up, disk near full. Any check your monitoring runs can fire a push.
- Works with your stack — Grafana, Prometheus Alertmanager, pgwatch, Datadog, and Zabbix POST to the webhook URL you already configure for other alerts.
- Severity in the title — A primary going down and a replica lag warning land as distinct alerts. GJSON mapping reads the severity from the payload into the title.
- Per-database channels — Each database gets its own application, so prod, staging, and the analytics replica never share a channel.
- Sub-second delivery — Pushes land in well under a second, fast enough to start a failover before the connection pool drains.
- No agent required — Nothing to install on the DB host. The monitoring you already run does the talking.
**FAQ**
- How do I get a push when my database goes down?
  Have your monitoring stack POST to a Pocket Alert webhook when a check trips. Grafana, Prometheus Alertmanager, pgwatch, Datadog, and Zabbix all support outbound webhooks, and a cron health script can curl the same URL.
- Which databases are supported?
  Postgres, MySQL, Redis, and MongoDB all work. Pocket Alert reads the JSON your tooling sends, so the database engine never matters. If it can fire a webhook or run a check script, it can reach your phone.
- Can I separate a primary outage from a lag warning?
  Give the primary and the replicas their own webhooks, or use a GJSON template that pulls the severity from the payload into the title. A primary outage and a replica lag warning then read differently the moment they land.
- How do I keep prod and staging alerts apart?
  Give each database its own application and webhook URL. Prod, staging, and the analytics replica land in separate channels, so a noisy staging box never drowns out a real prod incident.
- Do I need an agent on the database box?
  No. Pocket Alert runs no agent on the database host. Whatever monitoring or health-check script you already have fires the webhook, and pushes arrive in under a second.
- Can a database-down alert wake me up at night?
  Yes. Send it with level=critical, or set default_level to critical on the webhook so everything it receives is loud. On Android, critical posts to a dedicated channel that bypasses Do Not Disturb once you grant DND access, and it can take over the screen; on iPhone it arrives as a time-sensitive notification that breaks through Focus. The free plan delivers critical as high, still instant, just without the DND override.
### Push matched log lines to your phone.
URL: https://pocketalert.app/use-cases/log-monitoring-alerts
Loki, the ELK stack, Graylog, or a tail | grep script already spots the error spikes and failed-login bursts. The matched line lands on your phone in under a second, so the log entry that matters is in your pocket.
**Three steps from log line to push**
1. Define the pattern — Add a Loki ruler rule, an Elastic Watcher, or a grep pattern that triggers when a line matches.
2. Wire it up — Curl the messages API from a tail | grep script, or point Alertmanager at a Pocket Alert webhook receive URL with a GJSON template.
3. Split the channels — Give each service or environment its own application so prod and staging logs stay in separate channels.
**From log line to lock screen**
- Works with your stack — Loki ruler, Elastic Watcher, Graylog, or a tail | grep script can all post to one webhook.
- Pattern-matched alerts — A LogQL rule, a Watcher condition, or a grep pattern decides when the push goes out.
- Field mapping — GJSON paths pull the alert name, the matched line, and the hit count straight out of the alert JSON.
- CLI or webhook — A tail | grep script can curl the messages API directly, no monitoring platform required.
- Per-application channels — One Pocket Alert application per service or environment keeps prod and staging logs in separate channels.
- Sub-second delivery — The webhook fires and the push lands in under a second, fast enough to catch an OOMKilled pod live.
**FAQ**
- How do I get a push when a log pattern matches?
  Set up a Loki ruler alert, an Elastic Watcher, or a Graylog event definition that fires a webhook to your Pocket Alert application URL. The matched log line and count come through in the JSON body.
- Do I need to install an agent?
  Nothing extra runs on your boxes. Pocket Alert sits at the end of the pipeline you already have, so Loki, Elastic, Graylog, or a cron tail script does the matching and just posts the result.
- How do I map the log fields into a notification?
  GJSON field mapping reads any path in the alert payload. Pull the alert name into the title and the matched line or count into the message, for example %alerts.0.labels.alertname% and %alerts.0.annotations.summary%.
- Can I keep a 500s spike apart from a stray warning?
  Give each service or environment its own Pocket Alert application so a flood of 500s in prod lands in a different channel from a stray parser warning in staging. Quiet feeds stay separate from the ones that should wake you.
- How do I keep services and environments apart?
  Give each service or environment its own Pocket Alert application. Then prod auth-failures and staging job logs land in separate channels instead of one noisy feed.
- Can an error spike break through Do Not Disturb at night?
  Yes. Add "level":"critical" to the POST and Android delivers it on a dedicated notification channel that bypasses Do Not Disturb — you grant DND access once. On iPhone, high and critical arrive as time-sensitive notifications that break through Focus modes. You can also set default_level on the webhook so every alert from that pipeline arrives at the same priority, and keep chatty feeds at level silent — no sound or vibration, still in history. Free plan delivers critical as high: instant, but no DND override.
### Hear it when a sale lands.
URL: https://pocketalert.app/use-cases/ecommerce-order-alerts
Every new order from Shopify, WooCommerce, or your own store lands on your phone with the order number, total, and customer. Hear the cha-ching the second a sale comes in.
**Three steps to order alerts**
1. Create the webhook — Create a Pocket Alert webhook with a GJSON template mapping order_number, total_price, and customer, then copy its receive URL.
2. Point your store at it — In Shopify, add a webhook for the Order creation event and paste your receive URL as the destination.
3. Hear the cha-ching — Place a test order. The sale lands on your phone with the total and the customer.
**Your storefront, on your phone**
- Any store, no plugin — Shopify, WooCommerce, Stripe, Paddle, or a custom store POSTs its order webhook straight at your Pocket Alert URL.
- Total & customer — Map the order total, customer, and product so the push reads like a real receipt instead of a raw event.
- Sales, refunds, failures — A new order, a refund, or a failed payment each becomes its own push, sent from the same store webhook.
- Refunds on their own channel — A separate webhook for refunds/create on its own application rings apart from routine orders, so a refund never hides in the sales feed.
- Under a second — The order leaves the store and reaches your phone in under a second, no dashboard refresh in between.
- One channel per store — Point each store at its own application, so two brands ring on two channels you can tell apart.
**FAQ**
- How do I get an alert for new orders?
  Create a webhook in Pocket Alert with a message template, then paste its receive URL into Shopify under Settings, Notifications, Webhooks. Shopify fires the orders/create webhook on each order, and Pocket Alert renders it into a push.
- Can the alert show the total and customer?
  Yes. Your GJSON template pulls the fields straight from the Shopify payload — %order_number%, %total_price%, %currency%, and %customer.first_name% — so the push reads "Order #1001 · 125.00 USD · Jane".
- Which platforms work?
  Shopify, WooCommerce, BigCommerce, and any custom store that POSTs a webhook. Map each platform's own payload fields in the template — no plugin beyond the native webhook each platform already ships.
- Can a refund stand out from a sale?
  Yes. Create a separate Pocket Alert webhook for orders/create and another for refunds/create, each with its own application, so refunds ring on a channel you can tell apart from routine sales.
- I run two stores. Can I keep them separate?
  Give each store its own Pocket Alert application. Two brands, two channels, and the push tells you which one rang.
- Can I make a large order louder than the rest?
  Yes. Every message takes a level, from silent (-2) to critical (2). Post big totals from your backend with level high and they arrive as time-sensitive pushes that break through iPhone Focus, while a nightly revenue digest sent at silent lands in history without a sound. A webhook can carry its own default_level too, so a big-order webhook rings apart from the routine feed.
### Every form submission lands on your phone.
URL: https://pocketalert.app/use-cases/form-submission-alerts
A new contact form, demo request, or survey response from Typeform, Tally, or Formspree reaches your phone with the name and email attached. Never miss a fresh lead again.
**Three steps to form alerts**
1. Create the webhook — Create a Pocket Alert webhook with a GJSON template mapping the answer and email fields, then copy its receive URL.
2. Connect your form — Paste the receive URL into Typeform, Tally, or Formspree as the webhook destination.
3. Catch the lead — Submit a test entry. Your phone buzzes with the lead before they leave the page.
**Every form, straight to your pocket**
- Webhook in, push out — Paste your Pocket Alert webhook URL into the form tool and submissions start landing on your phone.
- Works with every form — Typeform, Tally, Formspree, Google Forms, and any custom handler all POST the same way.
- Map the fields you want — GJSON pulls the name, email, and message out of the payload, so the alert reads like a real lead instead of raw JSON.
- A template per form — Each Pocket Alert webhook renders its own template, so a demo form and a survey produce differently worded pushes.
- One channel per form — Give each form or site its own application and their alerts land on separate channels.
- Sub-second delivery — Submissions reach you in under a second, fast enough to answer while the lead is still browsing.
**FAQ**
- How do I get alerts when someone fills my form?
  Create a webhook in Pocket Alert with a message template, then paste its receive URL into Typeform, Tally, or Formspree as the webhook destination. Each submission POSTs to that URL and shows up on your phone with the name and email filled in.
- Which form tools work?
  Typeform, Tally, and Formspree all fire a webhook on submit. Custom sites and backend handlers POST the same JSON. Your GJSON template pulls the name, email, and message into the title and body.
- Can the alert show the actual answers?
  Map the fields you want with GJSON. For Typeform, %form_response.answers.0.text% is the answer to your first question and %form_response.answers.1.email% is the email field, so the push reads "New lead: Jane Doe" instead of a raw payload.
- Can I separate a demo request from a newsletter signup?
  Give each form its own Pocket Alert webhook and application. An enterprise demo request rings on one channel, a newsletter signup on another, so you can tell them apart at a glance.
- How fast does the alert arrive?
  Delivery is sub-second, so you can reply to a fresh lead while they still have your page open.
- Can a demo request ring louder than a newsletter signup?
  Yes. Each webhook can carry its own default_level, from silent (-2) to critical (2). Set the demo-form webhook to high and those pushes arrive as time-sensitive notifications that break through iPhone Focus, while the newsletter webhook runs at silent — logged in your history without a buzz.
### Every security event to your phone.
URL: https://pocketalert.app/use-cases/security-alerts
When something touches your server — an SSH login, a fail2ban ban, a CrowdSec or auditd rule — the user, source IP, and rule land on your phone in under a second. Know who logged in before they finish typing.
**Three steps to login alerts**
1. Get an API key — Create an API key and a per-host application, then keep the key in an environment variable on the box.
2. Hook the event — Add a curl to your login script, fail2ban action, or IDS rule that posts the user and source IP.
3. Watch your boxes — Logins and bans hit your phone within a second. Put the event in the title so a root login from a new IP reads clearly apart from a routine deploy.
**From login to push**
- SSH login push — A login script in /etc/profile.d or an sshrc curls Pocket Alert with the user and source IP on every interactive session.
- fail2ban bans — fail2ban runs a curl in its actionban, so each banned IP shows up on your phone with the jail that caught it.
- sudo and admin logins — A PAM hook or a sudo trigger fires when someone escalates, and a new admin login lands the same way.
- IDS and audit triggers — CrowdSec, Wazuh, OSSEC, and auditd shell out to curl on a rule match.
- Field mapping — GJSON field mapping pulls the user, source IP, and rule from a SIEM payload into the title and message.
- Sub-second delivery — Pushes land in well under a second, fast enough to catch a session while it is still open.
**FAQ**
- How do I get an alert on every SSH login?
  Drop a small script in /etc/profile.d that curls Pocket Alert with $USER and the IP from $SSH_CONNECTION. Every interactive login then pushes to your phone.
- Can fail2ban send me a push?
  fail2ban runs a curl in its actionban. Map the banned IP and jail into the message body, and you see each ban as it happens.
- How do I tell urgent logins from routine ones?
  Put the event in the title so it reads at a glance: a root login from a new IP and a routine deploy-user login land as clearly different alerts. Give sensitive hosts their own application to keep them apart.
- Does this work with CrowdSec, Wazuh, or auditd?
  Yes. CrowdSec, Wazuh, OSSEC, and auditd can all shell out to curl on a trigger. GJSON field mapping pulls the user, source IP, and rule into the title and message.
- How do I separate alerts per server?
  Give each host its own application: prod, bastion, personal. Per-application channels keep the alerts separate so you know which box raised the flag. Pocket Alert relays the event; it is not an IDS.
- Can a root login break through silent mode at 3am?
  Yes. Add "level":"critical" to the curl and Android posts it to a dedicated notification channel that bypasses Do Not Disturb — you grant DND access once. On iPhone, high and critical arrive as time-sensitive notifications that break through Focus modes. Keep routine deploy-user logins at level silent instead: no sound or vibration, but still in the history when you want the audit trail. On the free plan critical is delivered as high — still instant, just without the DND override.
### Get a push when the agent finishes.
URL: https://pocketalert.app/use-cases/ai-agent-alerts
A long-running LLM agent should not need you watching it. Your phone buzzes when the job is done, stuck waiting on approval, or broken — so you can step away and trust it to reach you.
**Three steps to hands-off agent alerts**
1. Pick MCP or HTTP — Create an API key, or add the Pocket Alert MCP server to your client for the no-code route.
2. Send on finish — Call create_message, or POST a title and message from a LangChain callback or agent tool.
3. Walk away — Give each agent its own application for failures and approvals. Now you can leave the desk while it works.
**Built for agents that run unattended**
- MCP server built in — MCP clients like Claude Code, Claude Desktop, and Cursor push a notification by calling the create_message tool.
- Plain HTTP fallback — No MCP client? One authenticated POST to the messages API does the same job from any agent or script.
- Stop-hook ready — Fire the alert from a Stop hook so it runs when the agent finishes, not when you remember to check.
- Status in the message — Send the agent status and result text right in the message, so "needs approval" reads clearly.
- Per-agent channels — A separate application per agent or project keeps the refactor bot and the cron job on their own channels.
- Sub-second delivery — Pushes land in under a second, so you hear back the instant a long job ends or stalls on input.
**FAQ**
- How does an agent send me a push?
  Two ways. MCP clients like Claude Code, Claude Desktop, or Cursor call the create_message tool and the push lands on your phone. Anything else does a single HTTP POST to the messages API. A Stop hook at end-of-run is the usual trigger.
- What is the no-code MCP path?
  Add the Pocket Alert MCP server to your client and call create_message with a title and message. No code, no curl. There is also create_message_with_attachment if the agent has a file or screenshot to send.
- Can I tell failures from completions at a glance?
  Give each agent its own application so a "needs approval" from your refactor bot and a "task done" from the nightly pipeline arrive on separate channels. Word the title so an approval request or a failure reads clearly at a glance.
- How do I keep agents from one project separate?
  Give each agent or project its own application. A push from your refactor bot and one from the nightly data pipeline arrive on separate channels, so you know which job spoke without reading the body.
- Is it fast enough to be worth checking the phone?
  Delivery runs under a second. When a coding agent has churned for fifteen minutes and you have wandered off to make coffee, the push reaches you before you sit back down.
- How do I keep completions quiet but failures loud?
  Send a level with each message. A routine "task done" ping can go at silent — no sound or vibration, but still in your history — while a failure or approval request goes at high and arrives as a time-sensitive push that breaks through iPhone Focus. The MCP create_message tool takes the same level field, so the agent picks the volume per message.
### Kubernetes alerts on your phone.
URL: https://pocketalert.app/use-cases/kubernetes-alerts
A CrashLoopBackOff pod, an OOMKilled container, a failed rollout, or a NotReady node turns into a push on your phone, with the namespace and pod name right on your screen. Catch cluster trouble without living in kubectl.
**Three steps from Alertmanager to phone**
1. Get a receive URL — Create a Pocket Alert webhook with a GJSON message template and copy its receive URL.
2. Wire up Alertmanager — Add a webhook_configs receiver in Alertmanager and route your critical alerts to it.
3. Ship it — The next firing alert pushes to your phone in under a second. Tune the GJSON template as you refine routes.
**From firing alert to phone**
- Native webhook_config — Alertmanager has a native webhook_config receiver. Point it at your application URL and you are done.
- GJSON field mapping — GJSON pulls alertname, namespace, pod, and severity out of the JSON into a readable title and message.
- Status and severity inline — Show status and severity inline so a firing critical alert reads differently from a resolved notice.
- Pod and node events — Catch CrashLoopBackOff, OOMKilled, failed rollouts, NotReady nodes, and PVC-full events.
- Per-cluster channels — Separate applications give prod and staging their own channels, each with its own webhook URL.
- Sub-second delivery — Pushes arrive in under a second once Alertmanager fires. No extra agent inside the cluster.
**FAQ**
- How do I send Kubernetes alerts to Pocket Alert?
  Add a webhook_configs receiver in Alertmanager pointing at your Pocket Alert receive URL, https://p4a.me/wh/1234abcd. A firing CrashLoopBackOff or OOMKilled alert becomes a push.
- How does Pocket Alert read the Alertmanager payload?
  GJSON field mapping reads Alertmanager JSON. Pull commonLabels.alertname into the title and alerts.0.labels.namespace / alerts.0.labels.pod into the body, so the namespace and pod show up on your screen instead of raw payload.
- Can I tell firing apart from resolved?
  The payload carries status (firing or resolved) and commonLabels.severity. Reference both in your GJSON message template so a firing critical alert reads differently from a resolved notice.
- How do I split prod and staging clusters?
  Give prod and staging their own Pocket Alert applications, each with its own webhook URL. Point one Alertmanager route at each so a NotReady node in staging never gets confused with prod.
- Do I need an agent running in the cluster?
  No. You already run Alertmanager. Pocket Alert needs nothing extra inside the cluster. A controller or script can also POST straight to https://api.pocketalert.app/v1/messages with a Token header.
- Can I map alert severity to notification priority?
  Yes. Every message accepts a level — silent, low, default, high, or critical. Include a "level" field in the webhook payload, or set default_level on the webhook itself; an explicit level in the payload always wins. A common split is firing=critical and resolved=silent: the firing alert breaks through Do Not Disturb on Android and lands time-sensitive on iPhone, while the recovery sits quietly in history. An invalid value falls back to default, never rejected.
### Know when a reading crosses the line.
URL: https://pocketalert.app/use-cases/iot-sensor-alerts
A temperature, humidity, water-leak, motion, door, power, or battery sensor crosses a threshold and the reading lands on your phone — from an ESP32, a Raspberry Pi, Home Assistant, or Node-RED. No broker and no MQTT bridge required.
**Three steps to sensor alerts**
1. Get a token or URL — Create an API key, or copy an application webhook URL for a room or device.
2. Fire on a threshold — Add the POST to your Arduino HTTPClient sketch, MicroPython script, Pi cron, or HA rest_command.
3. Read it on your phone — Trip the sensor and your phone buzzes in under a second, in the application for that board.
**Push alerts from any sensor**
- Fits a microcontroller — A plain HTTP POST fits an ESP32 or ESP8266 with room left over. No broker, no bridge.
- A channel per sensor — One application per board lets a water-leak alert read loud while a battery notice stays calm.
- Per-device channels — One application per room or device keeps garage, fridge, and greenhouse in separate channels.
- Map your own payload — GJSON field mapping pulls the sensor name and value out of the JSON your firmware already sends.
- Works with your setup — Arduino, MicroPython, a Pi curl, a Home Assistant automation, or a Node-RED flow all reach the same endpoint.
- Sub-second delivery — A threshold trips and the push lands in under a second, before a leak spreads or a freezer thaws.
**FAQ**
- How do I send an alert from a sensor?
  Your board makes one HTTP POST to the messages API when a reading crosses a threshold. On an ESP32 or ESP8266 that is a few lines of Arduino with HTTPClient or MicroPython; on a Raspberry Pi it is a curl. The payload carries a title and a message, with the API key in a Token header.
- Do I need MQTT or a broker?
  A plain HTTPS call fits inside an ESP32 with memory to spare. No MQTT broker and no bridge container to babysit. Home Assistant rest_command and Node-RED still work if you already run them.
- Can urgent readings stand out from routine ones?
  Give each board its own application so the freezer, the greenhouse, and the leak sensor land in separate channels. Word the title so a water leak reads loud at a glance, while a battery-low notice stays calm in its own app.
- How do I keep rooms and devices apart?
  Make one application per room or device. The garage, the fridge, and the greenhouse each land in their own channel, so you read the alert without squinting at which board sent it.
- Can it read my existing sensor payload?
  Point GJSON field mapping at the keys your firmware already sends. The sensor name and the reading slot straight into the title and message without reshaping the JSON on the board.
- Will a water leak alert get through Do Not Disturb at night?
  Yes. Add "level":"critical" to the POST and Android delivers it on a dedicated notification channel that bypasses Do Not Disturb — you grant DND access once. On iPhone, high and critical arrive as time-sensitive notifications that break through Focus modes. Send a battery-low notice as level silent instead: no sound or vibration, it just sits in the history. On the free plan critical is delivered as high — still instant, without the DND override.
### TradingView alerts, on your phone, instantly.
URL: https://pocketalert.app/use-cases/tradingview-alerts
Point a TradingView alert at a Pocket Alert webhook URL and the signal arrives on your iPhone or Android as a push notification in under a second. Map the payload into your own message format, and mark stop-loss alerts critical so they break through Do Not Disturb.
**Three steps from chart to pocket**
1. Get a webhook URL — Create a webhook in Pocket Alert with a message template and copy the receive URL.
2. Point TradingView at it — Paste it into the alert's Webhook URL field and write the alert message as JSON.
3. Trade with your phone on — Signals land as push notifications. Stop-loss alerts marked critical break through DND.
**From chart signal to pocket in a second**
- Native webhook, no bot — Paste a Pocket Alert webhook URL into TradingView's alert dialog. No middleware, no Telegram bot to babysit.
- Your format, not theirs — Write the alert message as JSON with {{ticker}} and {{close}} placeholders, map fields with GJSON into a clean push.
- Critical when money moves — Stop-loss hit? Send it as critical and it breaks through Do Not Disturb. Routine crossovers stay at default.
- Sub-second delivery — A signal fires and your phone buzzes in under a second — faster than an email and harder to miss than a Telegram group.
- A channel just for trading — Keep trading alerts in their own application with its own color and icon, separate from deploys and server alerts.
- Signal history — Every signal is kept in history with delivery stats — scroll back and audit what fired during the night.
**FAQ**
- How do I connect TradingView to Pocket Alert?
  Create a webhook in Pocket Alert to get a receive URL, then paste it into the Webhook URL field of a TradingView alert. TradingView posts to it when the alert fires, and Pocket Alert renders it into a push on your phone. Webhook delivery is available on paid TradingView plans.
- Can I control what the notification says?
  Yes. Write the TradingView alert message as JSON using its placeholders — for example {"ticker":"{{ticker}}","price":"{{close}}"} — and map the fields in your Pocket Alert template with GJSON: "%ticker% crossed %price%". If you keep the alert message as plain text, set the template to * and the text is forwarded as-is.
- Can a price alert wake me up at night?
  Add "level":"critical" to the JSON in the alert message and the push bypasses Do Not Disturb on Android and cuts through Focus on iPhone. Use it for liquidation warnings or stop-loss hits; keep routine signals at default so they do not wear you down.
- Does this work with trading bots other than TradingView?
  Anything that can send an HTTP POST when a condition triggers: 3Commas, Cryptohopper, custom bots, exchange webhooks, or your own script watching an API. TradingView is just the most common source — the Pocket Alert side is identical.
- Can I review past signals?
  Every alert is stored in your message history with timestamps, so you can scroll back through the signals of the last week and check what fired when. The feed filters by application, so trading alerts can live in their own channel, separate from server noise.
### Watch the queue before it backs up.
URL: https://pocketalert.app/use-cases/queue-monitoring-alerts
A backed-up queue is easy to miss until messages pile up and users feel the delay. Have a small cron check read the depth with redis-cli, rabbitmqctl, or the AWS CLI and call Pocket Alert, and a stalled worker lands on your phone in under a second.
**Three steps to queue alerts**
1. Measure the queue — Read the queue depth in a cron script with redis-cli LLEN, rabbitmqctl, or the AWS CLI.
2. Fire on threshold — Call pocketalert send (or curl the messages API) when depth crosses your threshold.
3. Act in time — Your phone buzzes within a second. Drain the backlog before users notice.
**Catch the backlog while it is small**
- Depth thresholds — A threshold in your cron script fires the alert once depth drifts past the line you set.
- Stall detection — A runaway backlog or a fully stalled consumer sends a push while a brief blip stays under the line.
- Depth in the message — Drop the queue name and current depth straight into the title and message of the call.
- Any broker — redis-cli LLEN, rabbitmqctl list_queues, and the AWS CLI for SQS all return a number you can send on.
- Per-queue channels — Each queue gets its own application_id, so payments and email never blur together.
- Sub-second delivery — The push lands in under a second, fast enough to act before the backlog snowballs.
**FAQ**
- How do I get alerts for a backed-up queue?
  Run a small cron script that reads the queue depth and calls `pocketalert send` (or curls the messages API) when it crosses your threshold. Works with Redis `LLEN`, RabbitMQ `list_queues`, and SQS `ApproximateNumberOfMessages`.
- Can I separate a real stall from a brief backlog?
  Set the threshold in the script. A short, recoverable backlog never crosses the line, so only a genuine stall or a runaway depth sends a push notification.
- Which brokers can I read the depth from?
  Any broker you can query from the shell works. `redis-cli LLEN queue:emails`, `rabbitmqctl list_queues`, or the AWS CLI for SQS all return a number you can compare and send on.
- How does the queue name and depth show up?
  Put the queue name and the current depth straight into the title and message of the call, so the push reads `emails: 18420 pending` with no extra glue code.
- Can I split alerts per queue or service?
  Pass a different `application_id` per queue. The emails queue and the payments worker land in separate channels, so you read the alert and know where to look.
- Can a stalled queue alert break through silent mode?
  Yes. Give the alert `level=critical` and Android posts it on a channel that bypasses Do Not Disturb, while iPhone shows it as a time-sensitive notification that breaks through Focus. If you also push routine depth reports, send those with `level=silent` so they land in history without a buzz.
### Make Grafana alerts reach your phone.
URL: https://pocketalert.app/use-cases/grafana-alerts
When a Grafana alert rule fires, the alert name, severity, and status land on your phone in under a second. See trouble before the dashboard turns red, without keeping a screen open.
**Three steps to Grafana alerts on your phone**
1. Create a webhook — Create a Pocket Alert webhook with a GJSON message template and copy its receive URL.
2. Wire up the contact point — Add the URL as a Webhook contact point in Grafana Alerting and attach it to a notification policy.
3. Map and ship — GJSON maps status, alertname, severity, and the summary into your push. The next firing alert buzzes your phone.
**From firing panel to lock screen**
- A standard contact point — Add Pocket Alert as a Webhook contact point in Grafana Alerting. No plugin, no agent, works on Cloud and self-hosted.
- Map fields with GJSON — GJSON paths pull alertname, status, and the summary annotation straight out of the Grafana payload into your notification.
- Severity and status inline — Show the severity label and firing/resolved status right in the push so a critical alert reads differently from a recovery.
- A channel per team — Each application has its own webhook URL, so infra, app, and per-team alerts stay in separate channels.
- Sub-second delivery — The firing alert hits your phone in under a second, well before anyone opens the dashboard.
- Secret webhook URL — The webhook URL is your application secret over HTTPS. Rotate it whenever you need a fresh endpoint.
**FAQ**
- How do I send Grafana alerts to my phone?
  In Grafana go to Alerting → Contact points, add a Webhook contact point, and paste your Pocket Alert application URL. Attach it to a notification policy and the next firing alert reaches your phone in under a second.
- How does field mapping work?
  Grafana posts a JSON payload with status, a commonLabels block, and an alerts array. Pocket Alert reads it with GJSON paths, so you map commonLabels.alertname to the title, alerts.0.annotations.summary to the body, and status to show firing or resolved.
- Can I show severity and status?
  Yes. The payload carries the severity label at commonLabels.severity and a status of firing or resolved. Reference both in your GJSON message template so a critical firing alert reads differently from a resolved one.
- Can I split alerts by team?
  Give each Grafana folder or team its own application. Infra alerts and app alerts land in separate channels, and you can mute one without touching the other.
- Do I need a plugin?
  Nothing extra. Pocket Alert receives the webhook Grafana already sends from its alerting engine, so there is no plugin or agent to install. Works with Grafana Cloud and self-hosted alike.
- Can I map alert severity to notification priority?
  Yes. Every message accepts a level — silent, low, default, high, or critical. Include a "level" field in the payload, or set default_level on the webhook so everything routed to it arrives at that priority; an explicit level in the payload wins. A firing=critical, resolved=silent split works well: the firing alert breaks through Do Not Disturb, the recovery stays quiet in history. An invalid value falls back to default, never rejected.
### Make Datadog monitors land on your phone.
URL: https://pocketalert.app/use-cases/datadog-alerts
When a Datadog monitor triggers, the alert and its severity hit your phone in under a second. Catch the incident before it escalates to a page.
**Three steps to Datadog alerts on your phone**
1. Create a webhook — Create a Pocket Alert webhook with a GJSON message template and copy its receive URL.
2. Wire up the webhook — Register the URL in the Datadog Webhooks integration with a custom $EVENT_TITLE / $TEXT_ONLY_MSG payload, then call it from a monitor.
3. Map and ship — GJSON maps the event title, message, and transition into your push. The next trigger buzzes your phone.
**From breached monitor to lock screen**
- Plugs into Datadog webhooks — Register Pocket Alert in the Datadog Webhooks integration and call it with @webhook-pocketalert from any monitor.
- Template variables in, GJSON out — Datadog template variables fill the JSON body. GJSON paths in Pocket Alert pull the event title, message, and transition into your notification.
- Triggered vs recovered — Map $ALERT_TRANSITION so a triggered monitor reads differently from a recovery, right on your lock screen.
- A channel per environment — Each application has its own webhook URL, so infra, APM, and per-team monitors stay in separate channels.
- Sub-second delivery — The breach hits your phone in under a second, well before the escalation policy kicks in.
- Secret webhook URL — The webhook URL is your application secret over HTTPS. Rotate it whenever you need a fresh endpoint.
**FAQ**
- How do I send Datadog alerts to my phone?
  Create a Pocket Alert webhook, copy its receive URL, then register it in Datadog under Integrations → Webhooks. Call it with @webhook-pocketalert from any monitor message and the alert reaches your phone in under a second.
- How does field mapping work?
  In the Datadog webhook you define the JSON body with template variables like $EVENT_TITLE, $TEXT_ONLY_MSG, $ALERT_TRANSITION, and $LINK. Pocket Alert reads that JSON with GJSON paths, so your message template maps those fields into the notification title and body.
- Can I show the alert transition and severity?
  Yes. Include $ALERT_TRANSITION (Triggered / Recovered) or $ALERT_TYPE in the payload and reference it in the message template, so a triggered monitor reads differently from a recovery. Datadog also exposes $PRIORITY and $ALERT_STATUS if you want them in the text.
- Can I separate prod and staging?
  Register one webhook per environment or team and reference the right one from each monitor. Prod and staging land in separate channels you can mute independently.
- Do I need another agent?
  Nothing on a host. Pocket Alert receives the webhook Datadog sends from its monitor engine, so there is no extra agent beyond the Datadog Agent you already run.
- Can I map alert severity to notification priority?
  Yes. Since you define the webhook payload yourself, add a "level" field next to $EVENT_TITLE — silent, low, default, high, or critical — and Pocket Alert maps it to notification priority. Send critical from a paging monitor so it breaks through Do Not Disturb, or set default_level on the webhook and skip the field entirely; an explicit level always wins. An invalid value falls back to default, never rejected.
### Make a finished workflow buzz your phone.
URL: https://pocketalert.app/use-cases/github-actions-alerts
Pocket Alert sends GitHub Actions results to your phone as push notifications. Add one curl step to a workflow, and when a build, deploy, or release finishes, the result hits your iPhone or Android in under a second — no watching the Actions tab.
**Three steps to GitHub Actions alerts on your phone**
1. Create an application — Add an application in Pocket Alert and save your API key as the POCKETALERT_API_KEY repo secret.
2. Wire up the step — Add a notify step that curls the messages API, using if: failure() and if: success() to pick outcomes.
3. Map and ship — Pull repo, sha, and workflow into the message. The next run buzzes your phone.
**From workflow run to lock screen**
- One step in your workflow — A single curl call against the messages API turns any workflow step into a push. No runner setup, no extra service.
- Key as a repo secret — Read your API key from ${{ secrets.POCKETALERT_API_KEY }} so it stays out of logs and rotates from the dashboard.
- Alert on the outcomes you choose — Pair if: failure() and if: success() to push failed builds and green deploys as separate, clearly labeled messages.
- A channel per repo — Each application has its own ID, so per-repo and per-environment runs stay in separate channels.
- Sub-second delivery — The step fires the moment the job ends, so the result hits your phone in under a second.
- Full run context — Pull github.repository, github.sha, and github.workflow into the message so you know exactly which run it was.
**FAQ**
- How do I get GitHub Actions alerts on my phone?
  Add a step that runs curl against https://api.pocketalert.app/v1/messages with your API key in the Token header. Put it at the end of the job so a finished deploy or a failed build pushes straight to your phone.
- How do I keep the key secret?
  Store your API key as a repository secret and read it with ${{ secrets.POCKETALERT_API_KEY }}, sent in the Token header. The key never appears in logs and you rotate it from the Pocket Alert dashboard.
- Can I alert only on failure?
  Use if: failure() and if: success() on two separate steps. A failed build fires one message, a green deploy fires another, so you can wire only the outcomes you care about.
- Can I split alerts per repo?
  Give each repo or environment its own application. Frontend, backend, and release workflows land in separate channels you can mute independently.
- Can I include the commit and workflow?
  Reference run context like ${{ github.repository }}, ${{ github.sha }}, and ${{ github.workflow }} in the message body so the push tells you exactly which run finished.
- Which endpoint does the step call?
  The step calls https://api.pocketalert.app/v1/messages with a Token header and a JSON body of title and message. Add application_id to route the push to a specific app.
- Can a failed build be louder than a successful one?
  Add "level":"high" to the failure step body and the push cuts through Focus on iPhone and rings prominently on Android; "level":"critical" goes further and bypasses Do Not Disturb entirely. Green-deploy pings can go out as "level":"silent" so they land in your history without a buzz.
### Make any Zap reach your phone.
URL: https://pocketalert.app/use-cases/zapier-notifications
Turn any event from the 7000+ apps Zapier connects into a push on your phone, in under a second and with no code. The booking, the new lead, the row added to a sheet — straight to your pocket.
**Three steps to Zapier notifications on your phone**
1. Get an API key — Create an API key on the API Keys page for the Token header.
2. Wire up the Zap — Add a Webhooks by Zapier Custom Request action and POST it to the messages API.
3. Map and ship — Map trigger fields into title and message. The next Zap run buzzes your phone.
**From any app event to lock screen**
- Works with any Zapier trigger — The built-in Webhooks by Zapier action POSTs to your Pocket Alert URL, so any of 7000+ Zapier apps can push to your phone.
- Map fields in the Zap — Build the JSON Data field once and drop trigger fields into the title and message right inside Zapier.
- Route to any app — Set application_id in the body to route a Zap to a specific Pocket Alert app, so feeds stay separated.
- A channel per Zap — Each application is its own channel, so sales, support, and ops Zaps land in feeds you can mute apart.
- Sub-second delivery — The event hits your phone in under a second once the Zap runs, no polling on your end.
- Secret webhook URL — The webhook URL is your application secret over HTTPS. Rotate it whenever you need a fresh endpoint.
**FAQ**
- How do I send Zapier events to my phone?
  Add a Webhooks by Zapier action set to Custom Request, POST it to https://api.pocketalert.app/v1/messages with a Token header, and map trigger fields into the title and message. Any of the 7000+ apps Zapier supports can now push to your phone.
- How does field mapping work?
  In the Data field you build a JSON body and drop trigger fields into it. Map a record name into title and any details into message, so each notification reads exactly how you want.
- Can I split events by channel?
  Add application_id to the JSON body to route a Zap to a specific Pocket Alert app. Sales, support, and ops events then land in separate channels you can mute independently.
- Can I route Zaps to different apps?
  Point different Zaps at different application_id values. Each app is its own channel on your phone, so you keep noisy and urgent feeds apart.
- Do I need to write code?
  No code and no Zapier app to publish. The built-in Webhooks by Zapier action posts straight to the Pocket Alert messages API, so any trigger Zapier offers works out of the box.
- Can one Zap be louder than the others?
  Yes. Add a level field to the Data JSON, from silent (-2) to critical (2). Give the closed-won Zap level high so it lands as a time-sensitive push that breaks through iPhone Focus, and set the nightly report Zap to silent — it files into your history without a sound.
## Features (full text)

### Push notifications you can act on.
URL: https://pocketalert.app/features/action-buttons
Docs: https://info.pocketalert.app/features/action-buttons.html
Attach up to three buttons to any push. Open a link, fire an HTTP request, or copy a value — without unlocking your phone or opening a laptop.
**From plain alert to one-tap action**
1. Pick a type — Decide what the button should do: open a URL, call an endpoint, or copy a value.
2. Add it to the message — Add an actions array to your message with up to three entries, each with a type, label and value.
3. Tap it from your phone — Send it. The buttons appear on the notification and inside the message in the app.
**FAQ**
- How many buttons can a notification have?
  Three per message. They render in the order you send them, on both iOS and Android, and they stay available inside the message itself after the banner is dismissed.
- What can a button do?
  Three types. <code>view</code> opens a URL, <code>http</code> sends an HTTP request in the background with your own method, headers and body, and <code>copy</code> puts a value on the clipboard. Only <code>view</code> brings an app to the foreground.
- Where does an HTTP button send its request?
  Straight from your phone to your endpoint. Pocket Alert does not proxy the request and never sees the response body. Add whatever authentication header your endpoint expects and it travels with the button.
- Do my button labels show on iPhone?
  Android shows the exact label you send. iOS registers notification categories when the app launches and cannot create labels on the fly, so it shows a generic label per type — Open, Run, or Copy.
- Can webhooks add buttons automatically?
  Yes. A webhook can carry an action template with <code>%path%</code> placeholders filled from the incoming payload, so a Sentry alert arrives with an Open issue button pointing at that specific issue. Substituted values are JSON-escaped, so a payload cannot rewrite the URL.
- What happens if I tap a button twice?
  Tapping twice sends the request twice — repeats are not blocked, deliberately. If firing twice is expensive, make the endpoint idempotent. Action buttons are a paid feature; on free plans they are stripped server-side and the message is delivered without them.
### Send now, deliver later.
URL: https://pocketalert.app/features/scheduled-delivery
Docs: https://info.pocketalert.app/features/scheduled-delivery.html
Set an exact time or a relative delay on any message, up to 30 days out, and cancel it any time before it fires. No cron job, no worker process.
**Three steps, one extra field**
1. Add one field — Take a message you already send and add send_at with a time, or delay with an offset.
2. Keep the tid — You get back a tid and the resolved delivery time in your timezone and in UTC.
3. Cancel if needed — List pending messages any time, and cancel with a DELETE if plans change.
**FAQ**
- How do I schedule a push notification?
  Add <code>send_at</code> with an exact time or <code>delay</code> with a relative offset to any message. <code>send_at</code> accepts RFC3339, a Unix timestamp, or a plain <code>YYYY-MM-DD HH:MM</code>; <code>delay</code> accepts durations like <code>30m</code> and <code>2h</code>. Send one or the other, never both.
- How far ahead can I schedule?
  Thirty days. Anything further out is rejected rather than silently clamped.
- Which timezone is used?
  Your account timezone. A <code>send_at</code> of 2026-08-15 09:00 means nine in the morning where you are, not in UTC. Add an offset explicitly if you want to be unambiguous.
- Can I cancel a scheduled message?
  List pending messages with <code>GET /v1/messages/scheduled</code> and cancel one with <code>DELETE /v1/messages/scheduled/{tid}</code>. If delivery has already started you get a <code>409</code> instead of a half-cancelled message. Cancelling also deletes any attachment.
- What if the delivery time passes during downtime?
  It is delivered late, not dropped. If the service restarts past a delivery time, the message goes out on the next tick. The content sits encrypted at rest with your key from the moment you schedule it.
- Is scheduling available on the free plan?
  Scheduled delivery is a paid feature, and a free-plan request using <code>send_at</code> or <code>delay</code> returns <code>403</code> rather than being silently sent immediately. Priority and plan are resolved when you schedule, so a message scheduled as critical still arrives as critical.
### Your webhooks stop being a black box.
URL: https://pocketalert.app/features/webhook-history
Docs: https://info.pocketalert.app/api/webhooks/history.html
Every incoming call recorded with its headers, payload, rendered message and outcome. When an integration swears it sent the request, you can check.
**Find out what actually arrived**
1. Point a service at it — Create a webhook and point your service at its URL, as you would normally.
2. Open the history — Open the webhook in your dashboard and click through to its history.
3. Expand the call — Expand any call to see headers, body, the rendered message and what went wrong.
**FAQ**
- What is recorded for each webhook call?
  Timestamp, HTTP method, source IP, content type, query string, full headers, the raw body, payload size, the message your template produced, whether an alert was created, a failure reason when it was not, and how long processing took.
- How long is webhook history kept?
  7 days on Free, 30 on Starter, 90 on Medium and 365 on Large. Older calls are removed automatically, as are the oldest entries once a single webhook passes 1,000 recorded calls.
- Is the stored payload safe?
  Yes. Payloads are encrypted at rest with your personal key, the same as message content, and Authorization, cookie and API-key headers are replaced with [redacted] before anything is stored.
- A service says it sent the webhook but nothing arrived. Now what?
  The history tells you which. If nothing is recorded at all, the sender never reached us. If a call is recorded with an error, you get the reason: invalid JSON, an empty message from a %path% that does not exist in the payload, or a webhook that was disabled.
- Where do I see the history?
  Open the webhook in your dashboard and its history is right there, newest first, with each call expandable. There is also a REST endpoint if you would rather pull it programmatically, with filters for success and error.
- Does webhook history work on the free plan?
  Yes, with 7 days of retention. If you need longer, that is what the paid plans extend.
### Your alert history deserves more than a password.
URL: https://pocketalert.app/features/two-factor-auth
Docs: https://info.pocketalert.app/features/two-factor-auth.html
TOTP two-factor authentication with single-use recovery codes, enforced on the dashboard and in the app. Your API keys and scripts carry on untouched.
**Set up in two minutes**
1. Scan the code — Open Account → Security and scan the QR code with your authenticator app.
2. Confirm once — Enter one six-digit code to confirm. 2FA only switches on after a correct code.
3. Store the backups — Save the recovery codes somewhere other than the phone running the authenticator.
**FAQ**
- Which authenticator apps work?
  Any standard TOTP app: Google Authenticator, 1Password, Authy, Bitwarden, and anything else that scans a QR code and produces six-digit codes.
- Will 2FA break my scripts and API keys?
  No. 2FA applies to interactive logins on the dashboard and in the mobile app. API keys authenticate with the Token header and are never challenged, so your cron jobs, CI pipelines and monitoring hooks keep sending alerts untouched.
- What if I lose my phone?
  Use one of your recovery codes in place of the six-digit code. Each one works once. You can generate a fresh set at any time from Account → Security, which invalidates the old ones.
- What happens if I start setup and abandon it?
  It does not touch the 2FA you already have. The new secret sits in a pending slot and only replaces the active one once you confirm a code, so closing the tab halfway through cannot lock you out.
- How does 2FA change API login?
  Login returns a short-lived challenge instead of a token, and you exchange that challenge plus a code for the real JWT. Challenges live for five minutes. The code field accepts either a TOTP code or a recovery code.
- What stops someone guessing my code?
  Five failed codes lock the account for fifteen minutes and further attempts return 429. You also get an email whenever 2FA is enabled or disabled — if one arrives and it was not you, change your password immediately.
## Comparisons with alternatives (full text)

### Pocket Alert vs Pushover
URL: https://pocketalert.app/alternatives/pushover
Pushover has been delivering push reliably for over a decade, and its outbound API is as simple as they come. Pocket Alert covers the same ground and adds what sits around it: an inbound webhook endpoint per source, a log of every call that arrives, scheduled delivery, and action buttons on the notification itself.
**What Pushover does not cover**
- No inbound webhook URLs — Pushover speaks outbound only. Anything that just emits webhooks needs a script or a third-party bridge in between.
- Nothing to debug with — When an alert never arrives, there is nothing to inspect. No record of the call, the payload, or why it failed.
- History is per device — Messages live on each device separately and are not viewable on the website, so history depends on the phone in your hand.
- No scheduling — A message sends the moment you call the API. Delivering it at 9am tomorrow means running your own cron.
**Pushover pricing**: free — 30-day trial, then a purchase per platform; entry — $4.99 once per platform, after a 30-day trial; top — Pushover for Teams, $5 per user / month
**FAQ**
- What can Pocket Alert do that Pushover cannot?
  Pushover gives you an outbound API: your code makes the request, and everything before that request is your problem. Pocket Alert also gives every webhook its own inbound URL, so a service that only speaks webhooks can be pointed straight at it and the fields mapped with <code>%field.path%</code> placeholders. On top of that it records each incoming call, schedules messages for later, and puts up to three action buttons on the notification.
- Where does message history live?
  Pushover stores messages on each device separately, and they are not viewable from the website. Pocket Alert keeps message history on the account, so it is the same list on your phone and in the dashboard, with delivery statistics next to it.
- Can I schedule a message for later?
  Add <code>send_at</code> with an exact time or <code>delay</code> with a duration to any message. It is stored encrypted until the delivery time, up to 30 days out, and you can list or cancel anything still pending. Pushover has no scheduling — messages send when you make the request.
- How does the pricing compare?
  Pushover is $4.99 once per platform after a 30-day trial, with a 10,000 messages per month allowance; Pushover for Teams is $5 per user per month. Pocket Alert is a subscription: free for 50 messages a day, $6/mo for 1,000 a day, $25/mo for unlimited. For one person sending a handful of alerts, Pushover costs less over time. The subscription buys the webhook layer, the history and the scheduling.
### Pocket Alert vs ntfy
URL: https://pocketalert.app/alternatives/ntfy
ntfy is a good piece of software, and if you enjoy running your own infrastructure it is hard to argue with free and open source. Pocket Alert is the hosted version of the same idea: publish over HTTP, get a push on your phone, but with an account instead of a topic namespace, history that is kept rather than cached, and a record of every webhook call that comes in.
**Where self-hosted push gets expensive**
- Someone has to run it — Self-hosting means uptime, TLS, upgrades and storage are yours. The shared instance comes with no delivery guarantee.
- Nothing is kept — Messages live in the server cache and are dropped roughly 12 hours after delivery. There is no history to come back to.
- No payload mapping — The publisher formats the message, so any service with its own payload shape needs a script sitting in between.
- The topic is the password — On the public instance a topic is only as private as its name. Guessable topics are readable and writable by anyone.
**ntfy pricing**: free — Free on ntfy.sh without sign-up, or free forever self-hosted; entry — $6/month — 2,500 messages a day, 3 reserved topics; top — $25/month — 50,000 messages a day
**FAQ**
- How is Pocket Alert different from ntfy?
  ntfy is an open-source pub-sub service you either self-host or use through the shared ntfy.sh instance. Pocket Alert is a hosted account-based service: you get an API key and webhook URLs, and there is no server, TLS certificate or storage to look after.
- What happens to old messages?
  On ntfy, messages sit in the server cache and are dropped after about 12 hours. Pocket Alert keeps message history on the account, so the same list is in the app and in the dashboard, with delivery statistics beside it. Webhook calls are recorded separately for 7 to 365 days depending on plan.
- Can I point a service straight at it?
  On ntfy the publisher formats the message, so a service that emits its own JSON needs a script in between. A Pocket Alert webhook takes the raw payload and maps fields into the title and body with <code>%field.path%</code> placeholders, and the same placeholders can fill in an action button, so a Sentry alert arrives with a working link to that issue.
- How does scheduled delivery compare?
  Both schedule. ntfy delays a message up to three days; Pocket Alert accepts an absolute time or a delay up to 30 days, lists what is pending, and cancels anything that has not fired yet.
- Who can read my notifications?
  On the public ntfy.sh instance the topic name is effectively the password, unless you pay for a reserved topic. Pocket Alert works the other way round: an account with API keys, optional two-factor authentication, and message content encrypted at rest with your own key.
### Pocket Alert vs Pushbullet
URL: https://pocketalert.app/alternatives/pushbullet
Pushbullet is a device-sync tool with an API bolted on: it moves links, files and text between the machines you own. Pocket Alert starts from the other end. It is for the notifications your servers, cron jobs and payment providers generate, so it has priority levels, webhook endpoints, delivery history and buttons you can act on.
**Where Pushbullet runs out of road**
- No priority levels — Every push arrives the same way. Nothing separates a finished backup from a production outage at 3am.
- No inbound webhooks — Pushbullet pushes go out; nothing comes in. A service that only emits webhooks needs your own code in the middle.
- Nothing to debug with — No delivery statistics and no record of a failed call, so a missing alert leaves nothing to inspect.
- A tight free allowance — Free accounts are limited to 500 pushes a month, which a single noisy monitor can burn through in a week.
**Pushbullet pricing**: free — 500 pushes a month, 100 SMS a month; entry — Pro, $4.99/month; top — Pro, $39.99/year — the only paid tier
**FAQ**
- How is Pocket Alert different from Pushbullet?
  Pushbullet was built to move things between your own devices: links, files, clipboard, SMS from the desktop. Pocket Alert is built for alerts coming out of servers, scripts and services, which is why it has priority levels, inbound webhook URLs, a call log and action buttons instead of file transfer.
- Can I still send links from my computer to my phone?
  Yes. The Chrome extension sends a link, a selection or a note to your phone in two clicks, which covers the part of Pushbullet most people actually use daily. What it does not do is mirror phone notifications to the desktop or send SMS.
- Can I make some alerts louder than others?
  In Pushbullet every push arrives the same way. Pocket Alert has five levels, from silent to critical: routine jobs land quietly in the tray, and a critical alert breaks through Do Not Disturb. Each level is a separate Android channel, so the noisy ones can be muted without losing the urgent ones.
- What does each one cost?
  Pushbullet Pro is $4.99 a month or $39.99 a year, and free accounts are capped at 500 pushes a month by the API. Pocket Alert is free for 50 messages a day, $6/mo for 1,000 a day with five webhooks, and $25/mo for unlimited.
### Pocket Alert vs Simplepush
URL: https://pocketalert.app/alternatives/simplepush
Simplepush is about as small as a notification service gets: no sign-up, one key, one curl command. That minimalism is the appeal, and also the ceiling. Pocket Alert keeps the same one-line send and adds the parts you reach for once alerts come from more than one place: levels, webhook endpoints, history, and a dashboard to see it all.
**Where Simplepush stops**
- The free plan is a demo — Ten notifications a month is enough to try it. One cron job that reports nightly runs out on the tenth.
- No priority levels — Every notification lands with the same weight. There is no level that breaks through Do Not Disturb when it has to.
- No inbound webhooks — You format the message before you send it, so a service with its own payload shape needs a script in between.
- Nothing to look at afterwards — No web dashboard and no delivery statistics, so what happened after the request is out of view.
**Simplepush pricing**: free — 10 notifications a month; entry — $12.49/year, unlimited notifications; top — One paid tier
**FAQ**
- How is Pocket Alert different from Simplepush?
  Both turn a single HTTP request into a notification on your phone. Simplepush keeps the surface deliberately small: a key, a title, a message, an event. Pocket Alert adds the layer around it — priority levels, inbound webhook URLs with field mapping, a log of every call, message history, scheduling and a web dashboard.
- Which one is cheaper?
  Simplepush is free for 10 notifications a month, then $12.49 a year for unlimited. Pocket Alert is free for 50 a day and starts at $6 a month. For a handful of personal alerts a year Simplepush is cheaper; the free plans are the thing to compare if you are monitoring anything that fires daily.
- What about encryption?
  Simplepush offers end-to-end encryption on Android, so the server cannot read the message. Pocket Alert does not do end-to-end; it encrypts content at rest with a key held per account, redacts authorization headers before storing webhook payloads, and offers TOTP two-factor on the account. If the server never being able to read a message is your requirement, Simplepush covers it and Pocket Alert does not.
- How do I connect a service that only speaks webhooks?
  Point the service at a Pocket Alert webhook URL and map its JSON into the title and body with <code>%field.path%</code>. Every call is then recorded with its headers, payload and result, so when an alert does not arrive you can see whether it was ever sent.
### Pocket Alert vs WebhookBeam
URL: https://pocketalert.app/alternatives/webhookbeam
WebhookBeam does one job cleanly: catch a webhook from Stripe, Shopify or PayPal and tell you it happened. Pocket Alert covers that job and the ones next to it, because most alerting is not only webhooks. Scripts, cron jobs, CI pipelines and AI agents send to the same account, land in the same feed, and can be made loud or quiet per source.
**Where a webhook-only tool leaves you**
- No Android app — The product is iOS, desktop and email. There is no Android app listed, so half a team may be left on email.
- Webhook-only intake — Alerts start with an incoming webhook. A cron job or a deploy script has nothing to call directly.
- No priority levels — Every notification arrives the same way, with no level that overrides Do Not Disturb when a charge fails at 3am.
- No action buttons — You read the alert, then open a laptop to act on it. Nothing to tap on the notification itself.
**WebhookBeam pricing**: free — 50 notifications a month, 7-day history; entry — $5/month — 1,000 notifications a month, 30-day history; top — $15/month — unlimited notifications and unlimited history
**FAQ**
- How is Pocket Alert different from WebhookBeam?
  WebhookBeam watches webhooks: you create a URL, point Stripe or Shopify at it, and get a notification when it fires. Pocket Alert does that too, and also takes direct API calls from your own scripts, cron jobs and CI, so monitoring alerts and payment alerts end up in the same feed rather than two tools.
- Is there an Android app?
  Pocket Alert has native apps for both iOS and Android. WebhookBeam lists an iOS app, desktop notifications and email; there is no Android app on its site or in the Play Store as of August 2026.
- Can I build the message from the payload?
  Both extract fields from the incoming payload and drop them into the notification. Pocket Alert uses <code>%field.path%</code> placeholders, and the same placeholders can fill an action button, so a Stripe dispute can arrive with a working link straight to that charge.
- How does the pricing compare?
  WebhookBeam is free for 50 notifications a month with 7 days of history, $5/mo for 1,000 a month, and $15/mo for unlimited notifications and unlimited history. Pocket Alert is free for 50 a day with 7 days of webhook history, $6/mo for 1,000 a day, and $25/mo for unlimited messages with 365 days of history. If you need history kept forever, WebhookBeam Pro does that and Pocket Alert does not.
## Blog posts

- [Pocket Alert 2.0: Critical Alerts, Action Buttons and Scheduled Push Notifications](https://pocketalert.app/blog/release-2-0) — 8 September 2026. Priority levels that break through Do Not Disturb, buttons you can tap from the lock screen, scheduled delivery, webhook history, an MCP server for AI agents, a browser extension and a rebuilt mobile app.
- [A Fresh Coat of Paint – The Pocket Alert Redesign](https://pocketalert.app/blog/pocketalert-redesign) — 6 December 2026. We rebuilt Pocket Alert from the ground up — a brand-new design, a dark mode, and a pager we love even more. Here is the story, with a look back at where we started.
- [Official integration with Make](https://pocketalert.app/blog/make-com-integration) — 15.02.2026. We are excited to announce that Pocket Alert is now available as an official app on Make. Automate your push notifications with thousands of apps without writing a single line of code.
- [OpenClaw Integration (formerly ClawdBot, MoltBot)](https://pocketalert.app/blog/openclaw-skill-integration) — 29.01.2026. Get instant push notifications from your OpenClaw AI assistant directly to your phone using Pocket Alert CLI. Learn how to connect OpenClaw (formerly ClawdBot, MoltBot) in minutes.
- [How to сonnect LemonSqueezy Webhooks to Pocket Alert for sales notifications?](https://pocketalert.app/blog/how-to-integrate-lemonsqueezy-into-pocketalert) — 29.01.2025. A few simple steps to set up push notifications for sales in LemonSqueezy
- [How to integrate Grafana into Pocket Alert?](https://pocketalert.app/blog/how-to-integrate-grafana-into-pocketalert) — 25.01.2025. A few simple steps to connect Grafana to Pocket Alert
- [Create your first webhook URL](https://pocketalert.app/blog/create-your-first-webhook-url) — 25.01.2025. A few simple steps to create webhooks in Pocket Alert
- [Release 1.0.7](https://pocketalert.app/blog/release-1-0-7) — 1 November 2025. New release 1.0.7 is here!
- [How to integrate Pulsetic webhooks into Pocket Alert?](https://pocketalert.app/blog/how-to-integrate-pulsetic-webhooks-into-pocketalert) — 18.06.2024. A few simple steps to connect Pulsetic webhooks
- [Release 1.0.6](https://pocketalert.app/blog/release-1-0-6) — 29.06.2024. New release 1.0.6 is here!
- [How to integrate GitHub webhooks into Pocket Alert?](https://pocketalert.app/blog/how-to-integrate-github-webhooks-into-pocket-alert) — 19.06.2024. A few simple steps to connect GitHub webhooks
- [How to integrate Bitbucket webhooks into Pocket Alert?](https://pocketalert.app/blog/how-to-integrate-bitbucket-webhooks-into-pocket-alert) — 18.06.2024. A few simple steps to connect Bitbucket webhooks
- [Release 1.0.5](https://pocketalert.app/blog/release-1-0-5) — 16.06.2024. New release 1.0.5 is here!
- [Release 1.0.4](https://pocketalert.app/blog/release-1-0-4) — 31.03.2024. New release 1.0.4 is here!
- [Release 1.0.3](https://pocketalert.app/blog/release-1-0-3) — 19.02.2024. New release 1.0.3 is here!
- [Release 1.0.2](https://pocketalert.app/blog/release-1-0-2) — 2 July 2024. New release 1.0.2 is here!
- [Release 1.0.1](https://pocketalert.app/blog/release-1-0-1) — 27.12.2023. New release 1.0.1 is here!
- [Introducing Pocket Alert](https://pocketalert.app/blog/introducing-pocket-alert) — 20.10.2023. First, I'll answer the most popular questions and tell you what Pocket Alert is, who it was created for, and what problems it solves.

Markdown of any blog post: append .md to its URL, or send `Accept: text/markdown`.