Webhook monitoring and alerting
Build metrics from fields in your event payloads, chart them on dashboards, and get alerted when a value crosses a line or when a source stops sending.
The problem
Most failures in event-driven systems are silent. A payment provider stops sending webhooks because a secret rotated. A sensor battery dies. A partner changes a field and your totals drift. Nothing throws, so nothing pages anyone.
Typical monitoring tools want you to instrument your own code. But the events are already flowing through one place, and the questions are simple: how many arrived, what is the average of this field, and did anything arrive at all in the last ten minutes?
Wiring a metrics pipeline, a dashboard tool and an alert manager to answer those is more machinery than the question deserves.
How Eventeer handles it
Metrics from JSON fields
Choose count, sum, avg, min or max, point at a field with a JSON path and optionally filter. Eventeer keeps 1-minute buckets for 30 days.
Dashboards
Time series, stat tiles and live event feeds on a 12-column grid, with ranges from 15 minutes to 30 days. Every new organization starts with an Overview dashboard.
Threshold and quiet alerts
Alert when an aggregate over the last N minutes passes a limit, or when a listener or one device has sent nothing for N minutes.
Email or webhook channels
Notify members by email or call a destination with a signed JSON body. Each rule can use several channels.
Incidents resolve themselves
An incident opens when a rule breaches and closes when it recovers, with a resolved notification. The incident history is available per rule.
Two kinds of alert rule
A threshold rule compares a metric over a window, for example average temperature above 80 over 5 minutes. An absence rule watches a listener or a single device, for example pump-17 silent for 10 minutes. A threshold rule with no data in the window counts as not breached, so use an absence rule to catch silence.
Limits
Plans include 10, 50 or 250 metrics and 5, 50 or 250 alert rules. Evaluation runs while your organization has a valid plan and pauses together with ingestion when it does not. See pricing for the full table.
Pair it with the rest
Alerts work on any source: inbound webhooks, device sockets or WebSocket feeds Eventeer dials out to.
What it looks like
A metric and an alert rule are two API calls. The same objects are available in the app, where you can also build dashboards.
# Metric: average of $.temp from one listener, in 1-minute buckets
POST /api/v1/metrics
{"name":"Pump temperature","listener_ids":["…"],"aggregation":"avg",
"value_path":"$.temp","unit":"°C"}
# Alert: fire when that average is above 80 over 5 minutes
POST /api/v1/alert-rules
{"name":"High temp","kind":"threshold","metric_id":"…",
"operator":"gt","threshold":80,"window_min":5,"cooldown_min":60,
"channels":[{"type":"email","to":["oncall@example.com"]}]}
# Webhook channel body (signed like any destination)
{"type":"alert","status":"firing","rule":{"id":"…","name":"High temp"},
"value":83.1,"threshold":80,"opened_at":"…"}Questions
- What can a metric measure?
- Count, sum, average, minimum or maximum of a numeric field picked with a JSON path such as $.order.amount, grouped into 1-minute buckets. An optional filter keeps only events matching one condition. Metrics are not backfilled: they start when you create them.
- How does an alert resolve?
- Rules are evaluated every minute. When a breached rule stops being breached, the incident gets a resolved time and a resolved notification is sent. While it keeps firing, you are re-notified only after the cooldown you set, or never if the cooldown is 0.
- Where do alerts go?
- To email addresses of organization members, or to an existing destination as a signed webhook, which suits Slack bridges or paging tools. Alert webhooks are not metered as delivered events.
Know when your events change
Add a metric to a listener, set an alert, and hear about the problem before your customers do.