# Kubernetes alerts on your phone.

> Send Kubernetes alerts to your phone. Point an Alertmanager webhook_config at Pocket Alert and CrashLoopBackOff or OOMKilled arrives as a push in under a second.

<!-- source: 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

Keep the Alertmanager you already run. Pocket Alert 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.

## Send Kubernetes alerts to your phone

### 1. Create a Pocket Alert webhook

On the [Webhooks](https://pocketalert.app/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](https://prometheus.io/docs/alerting/latest/configuration/#webhook_config)):

```
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](https://info.pocketalert.app/api/webhooks/settings.html) cover every GJSON path and webhook option.

## 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.