Hi all, Sean and I chatted directly about the trigger logs demo, so sharing my feedback here too so it's on the list.
First, I'm really excited you're taking this on Sean. Watchers have been a blind spot since inception and this closes a lot of it. Having logs for watchers without needing triggerer access, plus a unified triggers list with failure count, failing since, and the exception, makes a failing watcher easy to diagnose. What I suggested, and Sean has agreed to fold in: - On the trigger detail, show which Dags are scheduled on the watched asset(s), and add a count of affected Dags to the triggers list so you can prioritize when several are failing. - Surface failing triggers on the Dag page. The common flow is “why hasn’t my Dag run?” → open the Dag → see that a trigger is failing → click through. Today you have to already suspect the asset. I’d keep this to direct dependencies to keep scope tight. - Add a “Failing triggers” stat on the dashboard next to Failed Dags, including orphaned triggers. Today the Triggerer shows green while a watcher has been failing. - Show the failing state on the asset chip itself, so users can tell “no messages arrived” apart from “we can’t read the queue.” - A tooltip on Orphaned explaining what it means and what to do, and a timestamp on Last Error so you can tell if it’s stale. On your question about other gaps: - The biggest one I hear from users is alerting when an asset doesn’t update by a certain time. With sensors, the timeout acts as a time-window alert, and losing that is one of the main things keeping people from moving to event-driven scheduling, or even using assets for Dag dependencies. An on_failure_callback for watchers would help with the failing-watcher case too. - Partition support for watchers has also started coming up. Thanks Sean, nice work! I'm really excited seeing this land. Constance On Mon, Nov 2, 2026 at 8:02 PM Ghaeli, Sean via dev <[email protected]> wrote: > > What I’m planning: > > * > A /triggers API endpoint that lists every trigger with its status, owner, and > last failure message > * > Each trigger’s logs readable through the API and compatible with the common > remote logging providers > * > A Triggers page in the UI > > Recording trigger owner and failures was merged in > https://github.com/apache/airflow/pull/76101, and the API endpoint is out for > review in https://github.com/apache/airflow/pull/76260 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
