Try flyctl releases -a myapp --image. This is what I see for one of my apps (v1):
flyctl releases --image -a myapp
VERSION STABLE TYPE STATUS DESCRIPTION USER DATE DOCKER IMAGE
v407 true release succeeded Secrets updated e@mail.tld 2023-01-20T15:10:02Z registry.fly.io/myapp@sha256:e026a18
v406 true release succeeded Deploy image e@mail.tld 2023-01-07T17:19:47Z registry.fly.io/myapp@sha256:e026a18
...
v404 true scale succeeded Scale VM count: ["app, 3"] e@mail.tld 2023-01-04T18:30:55Z registry.fly.io/myapp@sha256:e433b12
v403 true rollback failed Reverting to version 401 e@mail.tld 2023-01-04T18:23:05Z registry.fly.io/myapp@sha256:e433b12
v402 false release failed Deploy image e@mail.tld 2023-01-04T18:22:04Z registry.fly.io/myapp@sha256:4f1e04f
v401 true release succeeded Deploy image e@mail.tld 2023-01-04T17:38:26Z registry.fly.io/myapp@sha256:e433b12
There’s a flyctl history -a myapp command too, which may or may not be as useful…
App logs are kept around by Fly on a best-effort basis and so, if you’re looking to persist logs, see: Fly Logs over NATS
From what you’ve written here, I wouldn’t be surprised if it is a bug with the Fly control plane.
To unblock from such situations in the past, a scale up and back down again (ex: flyctl scale count <6> -a myapp => flyctl scale count <3> -a myapp) has worked just as nicely.
Consider sharing the affected app name. It may help Fly engs lurking around to take a look to see what actually went on.
If your spend is more than $29/mo, consider subscribing to the Launch plan, then email support: Fly.io Support: community vs email (Read this first) - #9 by eli