New machines remain in created and never start the container

[mywellbeingapp]

• The previous machine (***) was running this image and serving requests successfully.

• Since the last deploy, new machines remain in created and never start the container.

[lillian]

@mywellbeingapp

The previous machine (***)

What is the point of including a completely redacted machine ID? It is not useful information so you may as well leave it out altogether.

Please provide a real machine ID or app name so Fly.io staff can look at your app.
For the community to help, please provide more information about your app (such as the fly.toml and/or dockerfile). Also, look at the logs of your app (fly logs, or the dashboard at https://fly-metrics.net) to see if there is any more relevant information.

The post below has more extended thoughts on how to write a post that is most likely to get you the help you need:

Suggestions on asking for technical help on the web

Preamble This is unrequited advice for Fly users wanting help, and no-one needs to heed it. I am merely a Fly enthusiast, with a side-interest in technical mentoring. Should this post unduly ruffle feathers, I shall delete it. However, it may be helpful for new posters. Suggestions for improvements, or general comments, are welcome. Most questions posted here are incomplete, unreadable, and/or impossible to answer. A number of posters do not know that some folks who help here are hobbyists and …

[halfer]

@mywellbeingapp

Since the last deploy, new machines remain in created and never start the container.

Have a look at your logs in Grafana. A common issue is that a healthcheck has been configured, the app is taking a long time to initialise, and the healthcheck times out before the app can start listening for HTTP requests.