That does look pretty conclusive…
Right… It’s generally important to avoid single-machine deployments on Fly, 
.
Unfortunately it’s unclear what fixes these—or even what the underlying cause is.
(Older posts suggest that it’s a metadata synchronization lag within the infrastructure, 
, but those internals may have changed a lot in the interim.)
The Fly.io platform as a whole seems under increased strain this week, so perhaps simply waiting a little and then retrying machine re-creation, during off-peak hours, might shake things loose. (I would keep B listed but stopped—and then fly m clone machine A. This minimizes the odds of landing in the exact same (glitch-prone?) spot as before.) It might be that API calls are silently faulting during the machine’s setup phase, or that its particular physical host is having load-related network problems.
Failing that, it might suffice to create a new application, rather than an entire new organization, 
.