daily_etl_orders failed, task transform_orders
stg_orders ref to customer_id, rerun from step 5.no digging — your team handled it before. just decide.
Never debug the same pipeline failure twice.
When a data pipeline incident fires, D-Recall automatically pulls the alert and the relevant chat context into your incident channel — so on-call engineers stop re-solving things the team already fixed.
Alert fires
Your alerting tool triggers an incident on a connected service — an Airflow job failure, a DAG error, an orchestration break.
Context assembled
D-Recall pulls the alert and the recent, real conversation from your incident chat channel — nothing summarized, nothing guessed.
Posted automatically
The assembled incident lands in your incident channel within seconds, linked back to its real source — ready before anyone has to ask.
D-Recall sits between whatever fires your alerts and wherever your team already talks. It doesn't replace either one, it just closes the gap between them — and it's built to swap in whatever tools you actually run, not just the ones in the demo.
Nothing is summarized
Every piece of context links back to its real source. Nothing gets rewritten by a model and presented as fact.
Never auto-executes
D-Recall assembles and presents context. It never takes an action or modifies anything. A human always decides.
Minimal, visible access
Read and post access to one chat channel, read-only access to one alerting service. Nothing more, and always visible what's connected.
Delete anytime
Remove the chat app and the alerting webhook whenever you want. Two steps, nothing left behind.
Looking for real teams to try it.
Built specifically for teams dealing with messy, recurring data pipeline incidents. Looking for a few real design partners to run it on actual incidents, not a demo.