min_machines_running = 1 still scales the machine down to zero

Questions / Help
,
1

Hi, I would like some help, please. I followed this doc to set auto_stop_machines = 'stop' and min_machines_running = 1, but the machine still stops by itself after a few minutes. Did I miss something?

Thank you in advance.

PS E:\apps\apps\app_name> fly status
App
  Name     = app_name
  Owner    = personal
  Hostname = app_name.fly.dev
  Image    = app_name:deployment-01JH86C5BZDA96QBRG3ZZ3REX0

Machines
PROCESS ID              VERSION REGION  STATE   ROLE    CHECKS  LAST UPDATED
app     683d61dfd9ed18  83      sin     stopped                 2025-01-10T19:40:52Z

fly.toml

[http_service]
  internal_port = 8080
  force_https = true
  auto_stop_machines = 'stop'
  auto_start_machines = true
  min_machines_running = 1
  processes = ['app']

fly version

PS E:\apps\apps\app_name> fly version
fly.exe v0.3.61 windows/amd64 Commit: a867d6bd190c533de7cc3f0e58c7af1907ea1584 BuildDate: 2025-01-08T20:04:32Z
2

Hi… This can happen if the primary_region is something other than Singapore.

(You can check via fly ssh console -C 'printenv PRIMARY_REGION', after restarting the Machine.)

Aside: With only one Machine in the entire app, you would be better off with auto_stop_machines = 'off', but I’m guessing that this is a minimal test case—rather than your ultimate intended setup…

Aside2: Original version incorrectly said FLY_REGION. (Sorry!)

1 Like
4

Thank you for your help. I think it’s Singapore from running your suggeste command

PS E:\apps\apps\app_name> fly ssh console -C 'printenv PRIMARY_REGION'
Connecting to fdaa:a:b5e7:a7b:18a:ba7f:2e77:2... complete
sin

I am just testing the Fly’s scaling flow. On product launch, there will be minimum 1 machine standing by of course. I also want the machines to autoscale from 1 to X. Not sure how difficult the setup that will be but i’ll try :sweat_smile:

1 Like
5

I do wonder if this is a bug that’s happening at the moment. I have recently changed my min_machines_running from 3 to 5. Previously, changes like that did work fine but today it didn’t take effect even with multiple deploys.

1 Like
6

happening to me too! I have another project that the same settings does work fine with. The same settings does not work with current project, so I wonder.

(sorry for my English)

==== UPDATE ====

i have set
auto_stop_machines = 'off'
and run
fly deploy
but the machine still shut itself down in minutes. I wonder if I did something wrong. Any places to look?

8

Hey folks if you would be conformable sharing the app names you are having difficulty with here please do. If not please send an email to support and let me know!

9

i also encounter same case, my app name is “ks-bki”

10

Hi everyone, we are rolling a fix for this issue. It will complete in 20 minutes, after that, redeploying the apps will sync service definitions and fix the issue. ty!

1 Like
11

Are we sure this is fixed? I am still getting App {name} has excess capacity, autostopping machine

12

have you redeployed @bradw ? What is your app name?

13

yes. several times today.

14

Your app has two machines and it is configured to only keep one running under low load. In fact, only one of them is running, the message you are getting is for the second machine.

[http_service]
auto_start_machines = true
auto_stop_machines = false
force_https = true
internal_port = 3_000
min_machines_running = 1

Please, check the output of fly status

15

Maybe this is unrelated? I updated the toml file and the machine is continuing to run.

Now it looks like fly is in a loop on longer running processes?

For example, I am pulling 400 records from a third party API and saving them to a DB. Watching to logs all the data is processed but fly just sits. Then after a bit of time, fly reloads/retries(?) b/c the process runs again. I have no retry logic and I am not interacting with the app. I am just watching the logs.

After the second run, I get a Failed to Fetch.

I am using the same db locally and hitting the same API. The processing of the data runs fine locally.