pipeline-incident-triagelisted

# Pipeline incident triage Follow `references/incident-runbook.md` in order. Do not skip to a hypothesis. ## Opening move Ask exactly two things if they are not already clear, and only two: 1. Is the data stale, or is it wrong and already published? 2. What reads from it? Stale is a delay. Wrong and published is an emergency, and the first action is to stop the next run, not to debug. ## Gather the evidence yourself when you can Read `references/execution-model.md`. During an incident the difference between asking the user to run six commands and reading the answer directly is the difference between a five minute triage and a thirty minute one. **With the MCP server**, run these through `execute_sql_readonly` before asking the user anything: 1. Freshness and row count by partition on the suspect table. The partial load that reports no error shows up here and nowhere else. 2. `get_table_info` on the table and its upstreams, to see whether a schema moved under the pipeline. 3. Job history for the last 24 hours filtered to the tables involved, to find the job that actually failed rather than the task that reported it. **With the `gcloud` CLI**, add the Airflow and Cloud Logging side, which the BigQuery MCP server cannot see. Then ask the user only what you could not read: whether the numbers are wrong or merely late, and who consumes the table. ## Commands for the parts you cannot read ```bash # Which Airflow tasks failed in the last day gcloud composer env