Open a Heroku release war room the moment production looks wrong

Build me a release war room app that my team opens the moment something looks wrong in production. It is a single dense screen built for someone under pressure: the release timeline is the landing view, and the rollback button must be reachable in two clicks (click a release row, click Roll back). No nested navigation, no multi page wizards.

The main view is a reverse chronological timeline of releases across all of my Heroku apps. Build the app set from Heroku List Apps plus List Teams followed by List Team Apps for each team, then dedupe by app id so an app owned by a team does not appear twice. For each app call Heroku List Releases sorted newest first and cap it at roughly the most recent 25 releases per app, fetching apps in parallel with a modest concurrency limit so we do not burn the Heroku rate limit. Merge everything into one list ordered by release timestamp, newest at the top.

Each timeline row shows the app name, the version number, who deployed it, when (relative time like "14m ago" with the exact timestamp on hover), the release description, and the release status. When a release was itself a rollback, mark it clearly with a distinct colored chip that names the version it rolled back to. Heroku records a rollback as a new release pointing at an older slug rather than rewriting history, and the description reads like "Rollback to v123", so detect rollbacks from that description pattern and by noticing when a release reuses the slug of an earlier release. Keep the rollback entries in the timeline rather than collapsing them, because a series of rollbacks is itself the signal that an app is unstable.

Above the timeline put a sticky filter bar with a multi select for apps and a time window control with one click presets for the last hour, last four hours, last twelve hours, last twenty four hours and last seven days, plus a custom range. The window is the thing I reach for most during an incident, so the four hour preset has to be a single click from the default view. Add a manual refresh button and auto refresh the timeline about once a minute, showing when the data was last pulled.

Clicking a release opens a detail pane beside the timeline, not a separate page, so I never lose my place in the list. The pane loads four things, each fetched only when the pane opens rather than for the whole timeline. First, the full release record from Heroku Get Release: version, status, description, deployer, timestamp, and the slug it points at.

Second, the app's current settings from Heroku Get Config Vars. Show the variable names in a compact list with their values masked by default and a per row reveal toggle, since these are secrets and the app will be open on a shared screen during an incident. Highlight any variable name that also appears in a merged pull request title so configuration changes that relate to the shipped code are easy to spot.

Third, the tail of the app's runtime logs. Use Heroku Create Log Session to get a short lived log URL and fetch the last chunk from it, roughly the most recent 200 lines, rendered in a scrollable monospace block with its own refresh button. Make error and warning lines visually distinct so they are findable at a glance.

Fourth, the human readable "what changed": the GitHub pull requests that merged into that app's repository in the window between the previous release and this one. Let me map each Heroku app to a GitHub owner and repository once, and persist that mapping in the app so I never re-enter it. Then call GitHub List Pull Requests filtered to closed state, sorted by most recently updated, keep only the ones with a merge timestamp that falls between the previous release timestamp and this release timestamp, and call GitHub Get a Pull Request for each match to pull the title, the author, and the change size (files changed, additions, deletions). Show them as a short list with links out to GitHub. Important: build this from merged pull requests only. Do not promise or attempt a commit level diff, because there is no commit listing or commit comparison available here. If no repository is mapped for an app, show a small inline prompt to map one rather than an error.

From the detail pane I need three actions, laid out as a clear row of buttons at the top of the pane so they are never below the fold. The first is Roll back, which uses Heroku Roll Back Release to return the app to the previous good release, meaning the most recent successful release before this one that was not itself a rollback. Show me which version it will roll back to before I commit. Because this is destructive, put it behind a typed confirmation: I have to type the app name exactly to enable the confirm button, and the dialog restates the app, the current version, and the target version. Style it as the destructive action. After a successful rollback, refresh the timeline so the newly created rollback release appears at the top, and show a clear success state with the new version number.

The second action is Restart, which calls Heroku Restart All Dynos for that app, behind a simple confirm rather than a typed one since it is recoverable. Show the result inline with a timestamp so the team can see the restart already happened and does not double fire it.

The third action is File incident, which uses Linear Create Issue to open a ticket prefilled from the release: a title naming the app and version, and a description containing the app name, the release version, who deployed it, the timestamp, whether the release was a rollback, and links to each merged pull request in the window. Let me pick the Linear team and priority, remember my last used team as the default, and optionally choose a workflow state from Linear List Workflow States. Once a ticket exists, persist the issue identifier and URL against that release so the timeline row and the detail pane both show the linked incident from then on and nobody files a duplicate.

Every release also gets an Investigate this release button that starts an embedded background agent. The agent reads the runtime logs from Heroku Create Log Session, the release record from Heroku Get Release, the app's settings from Heroku Get Config Vars, and the merged pull requests from GitHub List Pull Requests and Get a Pull Request for the window between the previous release and this one. It then writes a short suspicion brief: the most likely culprit change named specifically, the evidence from the logs that supports it, any setting that looks related to what shipped, and an explicit recommendation on whether to roll back with a confidence level. Compare the current settings against what the shipped pull requests touched, because a configuration change alongside a code change is a common cause. Keep the brief tight, a handful of sentences plus a recommendation, not an essay.

The brief lands back in the app stored against that app and release version, so it renders inside the detail pane and puts a small badge on the timeline row indicating an investigation exists. Show the investigation state (running, done, failed), when it ran, and who started it, and allow a re-run that replaces the previous brief. The whole point is that the next person who opens the release sees the finding without rerunning anything.

Persist the app to repository mappings, the default Linear team and priority, the filed incident links, and the investigation briefs in the app's own storage. Handle missing permissions and API errors inline with a plain message and a retry, never a blank screen, because this app gets opened exactly when things are already going wrong.