NerveStax On-Call — AI alert triage for your data platform
AI investigates
every alert from
your data pipelines.
Real problems
reach you with
the cause found.
Point your data platform’s alerts at NerveStax — Airflow, dbt, or anything that can send a webhook. An AI agent investigates each one — reads the logs, checks what changed — closes the noise with an explanation, and sends real incidents to your on-call tool (PagerDuty, Opsgenie, Splunk On-Call) with the root cause already written.
Part of NerveStax — the same AI agents that build, test and fix data pipelines. See the whole platform ›
03:11:07 alert revenue_daily — SLA missed airflow · prod · fp 9f2c 03:11:09 triage oncall_triage picked it up get_task_log · list_dag_runs · get_lineage · recent merges 03:12:31 found Object RAW.ORDERS_STG_V2 does not exist — all 3 retries identical 03:12:44 cause renamed in analytics PR #291, merged two days ago 03:13:02 verdict not transient — retries cannot fix a renamed object 03:13:04 escalate → paged on-call diagnosis attached
What just happened, at 3am, with nobody awake: an SLA alert landed at 03:11. The agent read the logs, walked the lineage and checked recent merges. Two minutes later the on-call engineer got one page — with the root cause, the blast radius and the suggested fix already written. Nobody spent the first hour of the incident finding out what the alert meant.
- Receives
- Every alert your platform sends — Airflow, dbt, any webhook
- Investigates
- Logs, lineage and recent changes — read-only
- Resolves
- Noise and self-healed alerts, with the reasoning logged
- Escalates
- Anything it can’t prove resolved — diagnosis attached
The condition
“Task failed. Try 3 of 3.”
is not information.
Data on-call is broken in a specific way: the alert tells you something died — never what it means, and never whether it matters.
“The diagnosis starts after you’re awake”
A job name and a retry count. What broke, why, what’s downstream, whether the morning dashboards survive — all of that is an hour of logs, lineage and git history, done at 3am, from a phone.
“Half of what wakes you up is noise”
Transient infra hiccups. Retries that already self-healed. One upstream failure fanning out into forty downstream alerts. Every false page erodes the only thing an alert has going for it — being taken seriously.
“The first hour is archaeology”
Most of the time-to-resolution is spent before the fix even starts: working out which alert is the cause and which are echoes. It’s the same read-the-logs routine every time — which is exactly why an agent can do it.
One page.
Diagnosis attached.
Escalation isn’t a forwarded alert — it’s a written diagnosis. What lands in your on-call tool names the root cause, the change that caused it, what’s affected downstream and the suggested next step, with a link to the full investigation. Whoever gets it starts at the fix, not at the logs.
Delivery goes wherever your on-call lives — PagerDuty, Opsgenie, Splunk On-Call, or any paging API. And every escalation is persisted first, then delivered: a provider outage can delay a page, never lose the incident.
- Root cause
- RAW.ORDERS_STG_V2 does not exist. Renamed to ORDERS_STG in analytics PR #291, merged two days ago. All three retries hit the identical error — not transient.
- Impact
- mart.orders_daily blocked → 14 downstream assets, including the revenue_bi board report due 07:00.
- Next step
- Point stg_orders at the renamed object, or revert #291 — a one-line change either way.
- Transcript
- nervestax → alerts / #4821 — the full triage conversation, unlocked. Pick it up and turn it into the fix PR.
The page that
never fires.
Most alerts don’t deserve a human. An upstream that landed late, a retry that already succeeded, the fortieth echo of one real failure — the agent proves the alert resolved, writes the explanation into the record, and nobody’s phone makes a sound.
Deduplication catches the storm before it starts: one fingerprint, one triage — not forty conversations about the same failure.
02:41:18 alert stg_events late — freshness breach airflow · prod 02:41:20 triage upstream export ran 22:40 → 02:12 — vendor delay 02:41:55 check next run already succeeded · row counts in range 02:42:03 resolved downstream landed complete — nothing broke 02:42:03 no page reasoning saved to the alert record 09:00 you read it over coffee, not at 3am
Getting started
Point your alerts at it.
Keep your on-call.
Route your alerts
One webhook per project. Airflow failure callbacks, dbt run and test results, or any JSON your stack already emits — normalised into one alert taxonomy, deduped at the door.
It triages every one
The agent already knows your platform — lineage, run history, recent merges — and works with read-only tools. No fixes ship from a triage; code changes still arrive as pull requests you approve.
Every alert ends in a verdict
Resolved with reasoning, or escalated with a diagnosis. Nothing is silently dropped: if triage itself crashes, times out or is uncertain, it pages — fail-open, by design.
Trust
Built to be trusted
with your pager.
- Fail-open
- An uncertain or broken agent escalates. Crash, timeout, inconclusive verdict — anything short of a proven resolution pages a human. It can never silently eat an alert.
- Read-only triage
- During triage the agent holds read-only tools — no repo or write access while raw alert payloads are in its context, and payloads are fenced as untrusted input, never instructions.
- Persisted first
- Escalations are written to the record before delivery is attempted. A paging-provider outage delays the page; it cannot lose the incident.
- Storm control
- Fingerprint dedup plus a per-workspace cap: an alert storm short-circuits to escalation instead of burning your model spend on forty copies of one failure.
- Yours afterwards
- Every triage is a conversation in the product. When it ends, it unlocks — read every step it took, ask follow-ups, turn it into the fix.
Questions
What on-call engineers
ask us first.
Q01What can send it alerts?−
Anything in your data platform that can send a webhook. Airflow (task and DAG failure callbacks) and dbt (run and test results) are understood natively; everything else — Snowflake alerts, your observability tool, a custom check — lands through the generic webhook. If it can POST JSON, it can reach the agent.
Q02Do we need PagerDuty?+
No. Escalation delivers to PagerDuty, Opsgenie and Splunk On-Call (VictorOps) out of the box, or to any paging system with an API — and every escalation also lives in NerveStax itself with its full diagnosis, so no team is left out.
Q03What if the diagnosis is wrong?+
Every verdict carries its full transcript — each log it read, each check it ran — so a wrong diagnosis is visible in seconds, not discovered in a retro. And an uncertain agent doesn’t guess: it escalates as inconclusive rather than inventing a cause.
Q04Can it change things to fix an alert on its own?+
No. Triage is read-only. When the fix needs a code change, you get the diagnosis, and the fix ships the way everything ships in NerveStax — a tested pull request a human approves.
Q05How is this different from data observability?+
Observability detects and notifies — it adds better alerts to the pile. This consumes the pile: every alert is triaged to a verdict by an agent that knows your lineage, your runs and your recent merges. They compose — your observability tool can be a source.
Q06What does a bad night cost?+
Triage runs on your own model keys, itemised per alert conversation. Fingerprint dedup and per-workspace caps keep an alert storm from becoming an invoice — over the cap, alerts skip triage and escalate directly.