Hi Fly team,
Four stateless Machines in GRU remain in the dashboard registry after force destruction was accepted. The last checks were on 2026-10-17 at 12:46 UTC using flyctl v0.4.118.
| App | Retired Machine | Dashboard state |
|---|---|---|
| akrid-go-h3-demand | 48e7454a4d2308 | started |
| akrid-workers-tier-0 | d8d1374a4de2e8 | stopped |
| akrid-workers-tier-1 | 2863067f376368 | stopped |
| akrid-go-outbox | 2863060a360708 | stopped |
For each ID, fly machine destroy ID --app APP --force returned success. However:
- Individual
fly machine status ID --app APPstill reportsdestroyingand an unreachable host. fly machine list --app APP --jsonomits these records.- The dashboard GraphQL registry (
app.machines(active:true)) still lists all four. H3 remains shown as deployed, and H3/workers0/workers1 show three Machines instead of the two accessible ones.
All four retired Machines have no data-volume mounts. Our 23 accessible Machines across 13 apps are confirmed stopped, with HTTP autostart disabled, restart policy no and standby watchers disarmed. We deliberately keep services off between tests.
Could you please finalize deletion/reconcile the registry for these four IDs and correct the H3 app status and Machine counts? Please preserve all other existing Machines, app identities, networking, secrets and Redis data volumes. We do not want replacements or scaling up.
Please also confirm that the inaccessible H3 Machine cannot keep processing work, that queued destruction will be enforced on host recovery, and whether pending-destruction records incur charges. If charges resulted from provider cleanup delays, please advise how to have them reviewed privately.
GraphQL removeMachine was also checked and rejected as retired; pauseApp rejects the Machines platform. We have not deleted/recreated any app to work around the discrepancy. No credentials, logs or dataset backups are included.
Thank you.