I checked my code and all the setup files are correct but still getting this error
Consider running your image locally in Docker, and then testing it from your machine’s console. I’d wager that your machine is listening to localhost not 0.0.0.0, or it’s not listening to IPv4/IPv6, etc. In other words, the error is absolutely correct; you just need to find out why.
Please post your TOML file here, and your Dockerfile if you have one. Consider using the code formatting tools provided by the forum editing tools.
Okay i will send them ASAP
Coolio. Also consider reading this advice when you have a moment.
I dont understand, but the docker file showing well
FROM python:3.12-slim
WORKDIR /app
# Install system dependencies
# Added 'libpq-dev' for postgres and 'chmod' for script execution
RUN apt-get update && apt-get install -y \
curl \
build-essential \
libpq-dev \
libmagic1 \
&& rm -rf /var/lib/apt/lists/*
# Install specific Poetry version
RUN pip install poetry==2.2.1
# Copy dependency files first (better layer caching)
COPY pyproject.toml poetry.lock ./
# Disable virtualenv inside container and install dependencies
RUN poetry config virtualenvs.create false \
&& poetry install --only main --no-interaction --no-ansi --no-root
# Copy the rest of the application code
COPY . .
# 1. Create the static directory (so FastAPI mount doesn't fail)
# 2. Normalize Windows line endings for the shell entrypoint
# 3. Create non-root user
# 4. Give appuser ownership of the app directory
# 5. Make the start script executable
RUN mkdir -p /app/static && \
sed -i 's/\r$//' /app/start.sh && \
useradd -m -u 1000 appuser && \
chown -R appuser:appuser /app && \
chmod +x /app/start.sh
USER appuser
# Fly.io internal port
EXPOSE 8080
# Health check using internal port 8080
HEALTHCHECK --interval=30s --timeout=10s --start-period=5s --retries=3 \
CMD curl -f http://localhost:8080/ping || exit 1
# Execute the start script to start the web process
CMD ["./start.sh"]
app = 'pingback-backend'
primary_region = 'lhr'
[env]
PYTHONUNBUFFERED = "1"
[build]
[deploy]
release_command = "alembic upgrade head"
[processes]
app = "./start.sh"
worker = "celery -A tasks.celery_app worker --loglevel=info --queues=emails,default"
[http_service]
internal_port = 8080
force_https = true
auto_stop_machines = 'off'
auto_start_machines = true
min_machines_running = 1
processes = ['app']
[[http_service.checks]]
path = "/ping"
interval = "30s"
timeout = "20s"
grace_period = "60s"
method = "GET"
[[vm]]
memory = '1gb'
cpu_kind = 'shared'
cpus = 1
memory_mb = 1024
OK. Firstly, you don’t need this:
Your healthcheck is defined in your TOML. I am not sure Firecracker VM will run the Docker healthcheck, but I would remove it anyway. Rebuild and relaunch.
I would also remove this:
It only marks the image with metadata; it does not expose any ports.
Finally, I would comment this out temporarily, so that your app starts up without healthchecks:
Then, assuming your machine does not die, shell into your machine container, and see if the listener process is still alive (ps) and also list what ports it is listening on (netstat or similar). You may have to look at your app configuration to determine which interface, address, and port is configured. It might only be listening on localhost/127.0.0.1, which will not work.
Thank you so much let me check it out
I did what you said and still got the same error
You’ll need to give more information in order to obtain more assistance. Consider showing the terminal commands you used, and the responses, to determine what is running in your machine and the network addresses/ports that are being bound to.
(Make sure you use code formatting in these posts).
I think the error in your title, at least before you edited it it was edited, indicated that the Fly healthcheck was failing. If you are still getting the same error then you have not disabled the healthcheck. I suggest that you do so; you will need to redeploy to do that.
I’m the one who edited it, actually,
. (It was gigantic previously, four lines long.)
I get 200 OK responses from https://pingback-backend.fly.dev/, so possibly this is just another case of slow initial startup, during deploys…
The thing is that, fly.io has not deployed the failed versions
it deployed the one that was working ( almost 10 commits behind) so that’s why you are getting a 200 ok status code
In my experience, the “app is not listening” warning doesn’t abort the deploy; that’s why there is so much advice in the forum about SSHing in and running netstat, etc. This sounds more like a failing health check, like @halfer said.
I’d suggest starting fly logs in a separate terminal (and leaving it running there) and then trying fly deploy again—looking for other messages that it might be giving…
In general, we here in the community forum can’t poke around in your logs, see your recent commands, etc., so, echoing @halfer again, we can only go by what you yourself post.
I have fixed the issue thank you so much!
i really appreciate your effort and thank you Halfer
Mind sharing how you fixed it? ![]()
The main fix was in main.py.
Before, Fly’s health check was hitting /ping, but that request was still passing through the rate-limit middleware first. That middleware touches Redis, so a simple health probe was depending on Redis being ready. If Redis was slow or unhappy during boot, Fly could think the app was unhealthy even though the server code itself was fine. I changed it so /ping is excluded from rate limiting, just like /health, which makes Fly’s check lightweight and reliable.
I also changed startup so the scheduler does not block app boot. Previously setup_scheduler() ran directly during FastAPI startup. Now it gets scheduled right after startup begins, which lets the app bind its HTTP port faster. That matters because Fly only cares that your app starts listening on 0.0.0.0:8080 quickly enough.
Sorry for the late reply
I tried sending the fix on that day but i think replies are limited here per day I dont know