Pocket Alert
Sign up free
Log Monitoring

Push matched log lines to your phone.

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.

Get started freeSee how it works
Push in <1sLoki · ELK · GraylogNo extra agent
Features

From log line to lock screen

Your log pipeline already finds the bad lines. PocketAlert 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 PocketAlert 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.

Get started

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

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 PocketAlert. Create a webhook on the 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 cover GJSON mapping and per-application routing.

FAQ

Questions, answered

Set up a Loki ruler alert, an Elastic Watcher, or a Graylog event definition that fires a webhook to your PocketAlert application URL. The matched log line and count come through in the JSON body.

Nothing extra runs on your boxes. PocketAlert 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.

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

Give each service or environment its own PocketAlert 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.

Give each service or environment its own PocketAlert application. Then prod auth-failures and staging job logs land in separate channels instead of one noisy feed.

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.

The error line that matters, in your pocket.

Point your log pipeline at a webhook and get the next error spike on your phone.

Connect your logsRead the docs