# GRU: four Machines stuck destroying after force destroy; dashboard still shows one Machine started

**URL:** <https://community.fly.io/t/gru-four-machines-stuck-destroying-after-force-destroy-dashboard-still-shows-one-machine-started/28848>\
**Category:** Questions / Help\
**Tags:** machines, dashboard\
**Created:** [October 17, 2026, 12:53pm UTC](https://community.fly.io/t/gru-four-machines-stuck-destroying-after-force-destroy-dashboard-still-shows-one-machine-started/28848 "2026-10-17T12:53:38Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![akrid-tecnologia](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/akrid-tecnologia/32/50985_2.png) [@akrid-tecnologia](https://community.fly.io/u/akrid-tecnologia)\
**Post date:** [October 17, 2026, 12:53pm UTC](https://community.fly.io/t/gru-four-machines-stuck-destroying-after-force-destroy-dashboard-still-shows-one-machine-started/28848/1 "2026-10-17T12:53:38Z")

</div>

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 APP` still reports `destroying` and an unreachable host.
- `fly machine list --app APP --json` omits 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.

---

<div class="post-metadata">

**Author:** ![Sam-Fly](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/sam-fly/32/48731_2.png) [@Sam-Fly](https://community.fly.io/u/Sam-Fly)\
**Post date:** [October 18, 2026, 2:15am UTC](https://community.fly.io/t/gru-four-machines-stuck-destroying-after-force-destroy-dashboard-still-shows-one-machine-started/28848/3 "2026-10-18T02:15:13Z")

</div>

Stale states in some flyctl contexts isn’t unusual when force destroying against an unreachable host. If `fly machine status <ID>` is showing destroying, that indicates the force destroy was successful and the machines will be deleted once the hosts become available.

Essentially once the host comes up, it’ll check the machine status, see they’ve been marked deleted, and remove them instead of starting.

Machines on unreachable hosts are not billed and do not incur costs.