# Push matched log lines to your phone.

> Get a push when a log pattern matches. Wire Loki, the ELK stack, or Graylog to a Pocket Alert webhook and the matched error line reaches your phone in a second.

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

Your log pipeline already finds the bad lines. Pocket Alert carries them to your phone.

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

## Send a push when a log pattern fires

### 1. Curl straight from a tail | grep script (CLI)

Install the CLI, authenticate once, then tail the log and push every matching line.

```
sudo mv pocketalert /usr/local/bin/ && chmod +x /usr/local/bin/pocketalert
pocketalert auth YOUR_API_KEY
```

```
tail -Fn0 /var/log/app.log | grep --line-buffered "OutOfMemory" | while read -r line; do
  pocketalert send -t "OOM on $(hostname)" -m "$line"
done
```

Or POST directly to the messages API instead of the CLI.

```
tail -Fn0 /var/log/app.log | grep --line-buffered "ERROR" | while read -r line; do
  curl -X POST 'https://api.pocketalert.app/v1/messages' \
    -H 'Token: YOUR_API_KEY' \
    -H 'Content-Type: application/json' \
    -d "{\"title\":\"Log error\",\"level\":\"critical\",\"message\":\"${line//\"/\\\"}\"}"
done
```

### 2. Or forward Loki / Alertmanager via a webhook

Define a LogQL alerting rule in the Loki ruler that fires when matches exceed a threshold.

```
groups:
  - name: app-errors
    rules:
      - alert: HighErrorRate
        expr: sum(count_over_time({app="api"} |= "ERROR" [5m])) > 20
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "{{ $value }} ERROR lines in the last 5m"
```

The ruler routes to Alertmanager (`alertmanager_url`), which forwards to Pocket Alert. Create a webhook on the [Webhooks](https://pocketalert.app/webhooks) page with a GJSON template mapping the Alertmanager payload, then point a `webhook_config` at the receive URL.

```
curl -X POST 'https://api.pocketalert.app/v1/webhooks' \
  -H 'Token: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{"name":"Loki Alerts","application_id":"qm47b9pzxzxg","message":"%status%: %alerts.0.labels.alertname% — %alerts.0.annotations.summary%"}'
```

```
receivers:
  - name: pocketalert
    webhook_configs:
      - url: 'https://p4a.me/wh/1234abcd'
        send_resolved: true
```

An Elastic Watcher `webhook` action or a Graylog HTTP Notification event definition can POST to the same receive URL. The [docs](https://info.pocketalert.app/api/webhooks/settings.html) cover GJSON mapping and per-application routing.

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