Unpopular opinion: post-incident reviews are a waste of time if you don't change the tooling

The prevailing orthodoxy in incident management, particularly within the SRE and platform engineering circles, posits that the post-incident review (PIR), or postmortem, is the cornerstone of a mature reliability practice. We are instructed to blamelessly dissect timelines, unearth root causes, and derive actionable follow-up items. While I do not dispute the theoretical value of this exercise, I contend that its practical utility asymptotically approaches zero if the review's output does not materially alter the **observability and orchestration toolchain** itself. Documenting a "human procedural gap" or adding a line to a runbook is often a performative distraction from the systemic failure of our data pipelines and alerting systems to provide the correct signal at the necessary fidelity.

Consider a typical data pipeline incident: late-arriving data causes downstream dashboards to trigger false-positive alerts. A standard PIR might conclude with:
* **Action Item 1:** Update the runbook to check the source system's heartbeat before escalating.
* **Action Item 2:** Add a documentation note about the SLA of the third-party API.

These are, in essence, human-process bandaids. They increase cognitive load for the on-call engineer during the next incident. A tooling-centric review would instead demand changes that **automate the detection or circumvent the failure**. The true "follow-up" should be embedded in the infrastructure's code. For example:

```yaml
# Example of a tooling change: An Airbyte connection configuration
# that implements conditional execution based on source data freshness.
definition:
name: "orders_api_sync"
schedule:
cron: "0 */2 * * *"
check_conditions:
- type: "source_data_freshness"
threshold_hours: 1
action: "warn_and_skip_destination_write"
notification_channel: "incident_management_platform"
```

The output of a PIR should be a series of Jira tickets or GitHub issues targeted not at "Ops" or "SRE," but at the teams owning the data orchestration (e.g., Airflow, Dagster, Prefect), data ingestion (Airbyte, Fivetran), and monitoring (Prometheus, Grafana, Datadog) stacks. The metrics of a successful PIR shift from "Were follow-up tasks completed?" to:

* Was a new metric or log field instrumented to capture the previously ambiguous state?
* Was an alert threshold dynamically adjusted based on historical context, perhaps using a BigQuery model?
* Was a runbook action automated into a one-click remediation script, integrated into the paging platform?
* Was the data pipeline's DAG (Directed Acyclic Graph) refactored to include a new conditional branch or a more granular checkpoint?

Without this focus, we are merely creating a more detailed map of a broken territory, rather than repairing the roads. The fatigue engineers experience is not from writing PIRs, but from repeatedly navigating the same broken tooling landscape, armed only with increasingly verbose procedural manuals. The most valuable post-incident artifact is a merged pull request that makes the same category of incident impossible, or at least immediately obvious and actionable, next time. Otherwise, we are just chronicling our failures, not engineering them out of existence.