What makes health check critical?

Questions / Help
1

Hi I’m trying to deploy my node js project (using fastify), I’m using dockerfile here the code

FROM node:16.13-slim

# Install Fastify CLI
RUN npm install -g --unsafe-perm fastify-cli

# it's recommended to run an app as a non-root user. Handily this image comes with a 'node' user
USER node
RUN mkdir -p /home/node/app
WORKDIR /home/node/app

# Copy projects
COPY --chown=node:node dist/apps/be .

# Install depedencies
RUN npm ci --only=production

ENV NODE_ENV="production"

# To run App
CMD ["fastify", "start", "-l", "info", "app.js", "--address", "::"]

then i run

flyctl launch

After the deployment done, then i get message

image
image1328×84 8.23 KB

I was get issue like this previously, it because the / url not return 200, and it needed for fly.io healthcheck. I already adding it now. But this time i wanna create new deployment and get this issue again.

I check the request that coming by put this code on my project

void fastify.addHook('onRequest', (request, reply, done) => {
      console.log("Request URL : ", request.url);
      console.log("Request Method : ", request.method);
      done();
  });

But i got nothing

image
image2408×486 159 KB

2

You are right in that a failed healthcheck would indeed return a critical error. Without seeing your fly.toml I don’t know how you have your checks set up, but the first thing is that you can have both tcp and http healthchecks, neither or both. Like in my sample Fastify app I had both:

So it may be e.g you have just a http healthcheck, and so that fails to return, and hence the critical error. If so, I’d check the path in your fly.toml is indeed /. And maybe add a grace_period value if the app won’t start immediately with a 200 response to give it a second or two.

If there is some other error in your code causing the app to crash on your next deployment, again the healthcheck on / would fail and hence the deploy would fail too. You would need to increase the logging/verbose setting to get more data on that and why. Check it runs locally as that is usually the easiest place to debug, so request / locally, and only then deploy when it works.

3

Hi @Angga

Can you share your fly.toml (omitting anything that you might find sensitive)?

One common issue we have is when a fly.toml expects a certain internal_port but the server listens to another port. I can see you have an app listening on port 3000 per logs (thanks for sharing that) so your fly.toml should have internal_port = 3000.