Pull vs Push Alerting

Alert source pulls vs alert source pushes. Trade-offs.

The distinction

Pull alerting: the system polls for state. Prometheus scrapes targets every 15 seconds; alert evaluator runs the rule each tick.

Push alerting: the system pushes events. Datadog agents push metrics; Sentry pushes errors; CloudWatch alarms fire on push.

Most teams run a mix. Picking which one for which signal is the actual question.

When pull wins

Predictable infrastructure: services exposing /metrics endpoints, databases with exporters, hosts with node-exporter.

Centralised control over scrape intervals. Prometheus operators handle this well.

Best fit: Kubernetes-hosted services, internal infrastructure, anything where you control the target.

When push wins

Bursty events: errors, deploys, audit logs. Pull would miss them between scrapes.

Third-party services: SaaS products that send webhooks. You can't make them expose a Prometheus endpoint.

Mobile and edge: clients that may be offline at scrape time but online to push later.

Operational differences

Pull is easier to debug. You can see exactly when the last scrape happened; missing data is obvious.

Push is easier to scale. The producer controls rate; the consumer just absorbs.

Pull breaks if the target hides behind NAT. Push breaks if the consumer's queue is full.

Pick by signal type

Steady-state metrics, infrastructure health: pull (Prometheus).

Events, errors, audit logs: push (Datadog Events, Sentry, OpenTelemetry).

Hybrid stacks are the norm. Don't try to standardise on one model.