Run your whole Fly.io Machine fleet from one screen

I want an app that works as a control room for every Fly.io Machine we run. The Fly dashboard is minimal and the workflow is command-line first, so today nobody can see the whole fleet on one screen without running flyctl. Build this so an on-call engineer who has never touched flyctl can work it confidently.

The main view is a single table of every Machine across all of my apps. Load it with List Apps to get the apps in my organization, then List All Machines for the org to pull every Machine in one org-wide read rather than looping List Machines per app. Each row shows the app name, the Machine ID, the region, the size (CPU kind, CPU count and memory), the current state, and how long the Machine has been in that state, shown as a readable relative duration like "stopped for 4h 12m" and derived from the timestamp of its most recent state change. Give me filters for app, region and state, plus a free-text search on Machine ID and app name, and make the whole table sortable, defaulting to the most alarming rows first.

Highlight trouble so it finds the engineer instead of the other way round. Visually flag any Machine that is stopped or failed, and any Machine that is restarting repeatedly. For the restart-loop flag, prefer recent event data that already comes back with the fleet listing; only if it is not there should the app fetch List Events, and then only for Machines that are already in a non-healthy state, in a throttled background pass whose results are cached. Do not fetch per-Machine events for the entire fleet on load. Put a small summary strip at the top with counts of total Machines, running, stopped, failed and restart-looping, so the state of the world is obvious in one glance.

Clicking a Machine opens a detail panel next to the table without losing my filters. Populate it with Get Machine for the full current config and state, List Events for a reverse-chronological activity timeline, List Processes for what is actually running inside the Machine right now, and List Versions for the config version history. Render the events timeline in plain language with human-readable timestamps rather than raw event payloads, and in the version history show what changed between versions, especially image, resources and environment, so an engineer can spot "this broke right after the last deploy" instantly.

The detail panel has action buttons so on-call can act without opening a terminal: Start Machine, Stop Machine, Restart Machine and Suspend Machine. Only show the actions that make sense for the Machine's current state, show a clear in-progress indicator while the action runs, and refresh that Machine's row and panel afterwards so the new state and the reset time-in-state are visible immediately. If an action fails, surface the actual error message from Fly rather than a generic failure.

Destroy Machine should be available too, but guarded. Keep it visually separate from the safe actions and put it behind an explicit confirmation where the engineer has to acknowledge the specific app name and Machine ID before it proceeds, so a stray click on a crowded board can never delete anything. Once destroyed, remove the row and say plainly what was destroyed.

Add a "Diagnose this Machine" button in the detail panel that kicks off a background agent for that Machine. The agent reads the recent events, the running processes and the config version history, then writes a plain-English diagnosis back into the app saying what likely went wrong and what to do next. It should call out concrete patterns like out-of-memory kills, a crash loop that started right after a specific config version, health checks failing, or a Machine that was stopped deliberately rather than crashing, and it should end with a short recommended next action. Store each diagnosis against the Machine with a timestamp and show it in the panel, keeping previous diagnoses as history so an engineer can see whether this has happened before. While the agent is working, show that it is running so nobody clicks twice.

Under a completed diagnosis, add a follow-up button that posts it to our incident channel using the Slack Send a Message action. Let me pick the channel, and format the message so it stands alone for someone who was not looking at the board: app name, Machine ID, region, current state, the diagnosis, and the recommended next action. Mark on the diagnosis record that it has been posted, with when and to which channel, so we do not double-post the same thing into an incident.

Two things to get right technically. First, the org-wide reads need an organization-scoped Fly access token, not an app-scoped deploy token; if the connected token is app-scoped, the org endpoints will fail with a permission error, so detect that and show a clear message telling me to reconnect with an org-scoped token instead of rendering an empty or half-broken board. Second, Fly rate limits are roughly one request per second per action, so the fleet view must page through the cursor-paginated org-wide results properly, continuing until no cursor is returned, and cache what it fetched rather than hammering per-Machine reads. Reads should be batched and paced, with a manual refresh control and a visible "last updated" timestamp so I always know how fresh the board is.

Design it for a stressed on-call engineer at 3am: dense enough to see the whole fleet at once, legible at a glance, states colour-coded consistently, and no Fly jargon or raw API field names anywhere in the interface.