[PC01] instance refused connection. is your app listening on 0.0.0.0:3000?

Questions / Help
1

I have this error always appear in logs but doesn’t affect the running of server. but I am not sure why this one appear.
this part of my logs

00:14:12=> Booting Puma

00:14:12=> Rails 8.0.4 application starting in production

00:14:12=> Run `bin/rails server --help` for more startup options

00:14:13[PC01] instance refused connection. is your app listening on 0.0.0.0:3000? make sure it is not only listening on 127.0.0.1 (hint: look at your startup logs, servers often print the address they are listening on)

00:14:13waiting for machine to be reachable on 0.0.0.0:3000 (waited 5.068566572s so far)

00:14:14waiting for machine to be reachable on 0.0.0.0:3000 (waited 5.236504964s so far)

00:14:16SolidQueue-1.3.2 Started Scheduler (563.0ms)  pid: 678, hostname: "0802d6dfd13438", process_id: 175, name: "scheduler-2e8abe756d59f9493532", recurring_schedule: ["remove_expired_bookings", "clear_solid_queue_finished_jobs", "remove_past_blocking_periods", "remove_past_special_periods", "remove_expired_sessions", "complete_the_booking_when_check_out_pass"]

00:14:16[PM05] failed to connect to machine: gave up after 15 attempts (in 8.04504805s)

00:14:17[PM05] failed to connect to machine: gave up after 15 attempts (in 8.239410755s)

00:14:25[5bc0380a-d28e-4afe-b980-5527e50def6c] Started GET "/api/v1/organizations" for 66.241.124.167 at 2026-04-25 00:14:25 +00

any help ?

4

Readers will need to see your TOML config, mostly to see what port your app is listening on.

Also, check how your app is configured:

00:14:13[PC01] instance refused connection. is your app listening on 0.0.0.0:3000? make sure it is not only listening on 127.0.0.1 (hint: look at your startup logs, servers often print the address they are listening on)

5

@halfer Thanks for you reply, this my stg toml file. is there any something wrong ?

app = ‘app’
primary_region = ‘cdg’
console_command = ‘/rails/bin/rails console’

[build]

[deploy]
release_command = “bundle exec rails db:migrate”
strategy = “rolling”

[deploy.release_command_vm]
size = “shared-cpu-1x”

[http_service]
internal_port = 3000
force_https = true
auto_stop_machines = ‘stop’
auto_start_machines = true
min_machines_running = 0
processes = [‘app’]

[processes]
app = “bin/rails server -b 0.0.0.0 -p 3000”

[[vm]]
memory = ‘1gb’
cpu_kind = ‘shared’
cpus = 1
memory_mb = 1024
processes = [‘app’]
6

@halfer Also, check how your app is configured:
which files you want to see ?

CMD of docker file

EXPOSE 3000

CMD ["bin/rails", "server", "-b", "0.0.0.0", "-p", "3000"]

puma conf:

threads_count = ENV.fetch("RAILS_MAX_THREADS", 3)

threads threads_count, threads_count

# Specifies the `port` that Puma will listen on to receive requests; default is 3000.

port ENV.fetch("PORT", 3000)


# Allow puma to be restarted by `bin/rails restart` command.

plugin :tmp_restart


# Run the Solid Queue supervisor inside of Puma for single-server deployments

plugin :solid_queue if ENV["RUN_SOLID_QUEUE"] == "true"

# Specify the PID file. Defaults to tmp/pids/server.pid in development.

# In other environments, only set the PID file if requested.

pidfile ENV["PIDFILE"] if ENV["PIDFILE"]
7

A few remarks. It looks like your Rails server is binding to all interfaces, and on the correct port. You also mention the app is running normally. So, a good start.

00:14:13[PC01] instance refused connection

There are two cases where I’d suspect this error: app start-up, and high-load. The first case might be easy to check for; consider doing a no-change deployment, and watch your logs. I’d suggest also looking at your CPU graphs in Grafana; some apps take high levels of CPU only on start-up, and the CPU scheduler temporarily punishes the app for excessive load, compounding the temporary performance problem.

You could also experiment with a higher spec CPU. This is annoying if you only have problems at start-up, as you’d be paying over the odds for a CPU spec you don’t normally need. But it is perhaps worth consideration.

8

@halfer I am afraid this issue due to health check, maybe it looking for GET “/” while rails 8 working with “/up”? I am trying now to add health check configuration into toml file and see what will happen

9

There was no healthcheck in your TOML file, so I discounted that. A health check is not mandatory, and I would not add one presently; if your start-up phase is very slow, a healthcheck could make it worse. In such a scenario, if your healthcheck fails because it has timed out before the service is fully operational, Fly will not regard the machine as having booted up.

Of course, you can extend the timeout of your healthcheck, but I would only do that after working out if your slow boot time can be improved. I don’t know Rails or Puma, but I’d guess my machines would become OS-operational in less than a second, and maybe Apache/PHP would take another partial second. So my total boot time is going to be around 2 seconds.

Something is failing for you within 5 sec and 8 sec; maybe you could find out whether that’s Fly, or something in Rails/Puma. Also it may be worth looking at Blue-Green deployments, in case having rolling deployments are needed to cover slow start times.

10

If you have just one machine, I’d assume that your failure is from the Fly proxy i.e. it’s ordinary traffic that your app has dropped. Even if your boot time were speedy, a machine restart will still drop traffic. You need a scaled app and a one-at-a-time deployment strategy to maintain uptime.