Pocket Alert
Sign up free
Database Monitoring

Find out when your database stops answering.

A failed health check, a lagging replica, a disk creeping toward full. Your monitoring fires a webhook to PocketAlert 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.

Get started freeSee how it works
Push in <1sPostgres · MySQL · Redis · MongoNo agent on the box
Features

From the alert manager to your pocket

Your monitoring already knows when a database is unhealthy. PocketAlert puts that on your phone.

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.

Get started

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.

Wire your database monitoring to your phone

1. POST straight from a health-check script

A pg_isready check or a slow-query/connection-count query in a cron script can curl the messages API with your API key in the Token header:

#!/usr/bin/env bash
# /usr/local/bin/pg-health.sh (run from cron)
if ! pg_isready -h prod-db -p 5432 -q; then
  curl -X POST "https://api.pocketalert.app/v1/messages" \
    -H "Token: YOUR_API_KEY" \
    -H "Content-Type: application/json" \
    -d '{"title":"Postgres down","message":"prod-db: connection refused on 5432","level":"critical"}'
fi

The "level":"critical" field makes this push break through Do Not Disturb, so a primary going down at 3am actually reaches you. The critical alerts page covers how levels work.

The same pattern works for replication lag or a full data volume:

LAG=$(psql -tA -c "SELECT EXTRACT(EPOCH FROM (now() - pg_last_xact_replay_timestamp()))::int")
[ "$LAG" -gt 120 ] && curl -X POST "https://api.pocketalert.app/v1/messages" \
  -H "Token: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d "{\"title\":\"Replication lag\",\"message\":\"replica-1 is ${LAG}s behind primary\"}"

2. Or create a webhook for your alert manager

Create a webhook with a GJSON message template that maps your tooling's payload. Grafana, Alertmanager, pgwatch, Datadog, and Zabbix all POST their own JSON:

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

Drop the receive URL https://p4a.me/wh/1234abcd into the alert manager's webhook receiver. A cron check can also POST plain JSON to the same receive URL.

The webhook settings docs cover GJSON field mapping and per-application routing.

FAQ

Questions, answered

Have your monitoring stack POST to a PocketAlert 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.

Postgres, MySQL, Redis, and MongoDB all work. PocketAlert 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.

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.

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.

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

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.

Catch the outage before your users do.

Point your DB monitoring at a PocketAlert webhook and stop refreshing dashboards.

Create a webhookRead the docs