Kubernetes alerts on your phone.
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.
From firing alert to phone
Keep the Alertmanager you already run. PocketAlert turns its webhook output into a push on your 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.
Three steps from Alertmanager to phone
Get a receive URL
Create a PocketAlert webhook with a GJSON message template and copy its receive URL.
Wire up Alertmanager
Add a webhook_configs receiver in Alertmanager and route your critical alerts to it.
Ship it
The next firing alert pushes to your phone in under a second. Tune the GJSON template as you refine routes.
Send Kubernetes alerts to your phone
1. Create a PocketAlert webhook
On the Webhooks page create a webhook whose GJSON message template reads the Alertmanager payload (top-level status and commonLabels, plus an alerts array):
curl -X POST "https://api.pocketalert.app/v1/webhooks" \
-H "Token: YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{"name":"K8s Alertmanager","message":"[%status%] %commonLabels.alertname% (%commonLabels.severity%)\n%alerts.0.labels.namespace%/%alerts.0.labels.pod%\n%alerts.0.annotations.summary%","application_id":"qm47b9pzxzxg"}'You get an inbound URL like https://p4a.me/wh/1234abcd. Use one webhook per cluster to keep prod and staging apart.
2. Point Alertmanager at it
Add a webhook_configs receiver and route your critical alerts to it (Alertmanager docs):
receivers:
- name: 'pocketalert'
webhook_configs:
- url: 'https://p4a.me/wh/1234abcd'
route:
receiver: 'pocketalert'
group_by: ['alertname', 'namespace']Alertmanager POSTs its standard JSON; the GJSON paths above pull status, alertname, severity, namespace, and pod into the push. When the alert clears, status flips to resolved.
3. Or POST from a controller / kubectl
A controller or one-off script can call the messages API directly with a Token header:
curl -X POST "https://api.pocketalert.app/v1/messages" \
-H "Token: YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{"title":"CrashLoopBackOff","level":"critical","message":"api-7c9 in prod, 12 restarts","application_id":"qm47b9pzxzxg"}'The webhook settings docs cover every GJSON path and webhook option.
Questions, answered
Add a webhook_configs receiver in Alertmanager pointing at your PocketAlert receive URL, https://p4a.me/wh/1234abcd. A firing CrashLoopBackOff or OOMKilled alert becomes a push.
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.
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.
Give prod and staging their own PocketAlert applications, each with its own webhook URL. Point one Alertmanager route at each so a NotReady node in staging never gets confused with prod.
No. You already run Alertmanager. PocketAlert 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.
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.
Get cluster alerts off the laptop.
Point a webhook_config at your application URL and the next firing alert hits your phone.