[K8s] Server fails to start in 1.9.0 (Solution in comment)
See original GitHub issueIs it a duplicate question? Please search in Issues without filters: https://github.com/louislam/uptime-kuma/issues?q=
Describe the bug First of thanks for your hard work. Really happy that there’s someone on the community that understands the gap in today’s open source, of not having a tool that reliably tracks uptime. I came from using statping and that was the closest I got to a good tool for uptime monitoring, barring performance issues.
Anyways on to the issue. I upgraded to 1.9.0 and realized that the pod no longer started. The logs below show the error it threw.
To Reproduce Steps to reproduce the behavior:
- Be running 1.8.0 before
- Pull and run 1.9.0 with the same settings as before.
Expected behavior Server starts
Info Uptime Kuma Version: Using Docker?: No but using Kubernetes Docker version: NA Node.js Version (Without Docker only): OS: Linux Browser: NA
Screenshots If applicable, add screenshots to help explain your problem.
Error Log It is easier for us to find out the problem.
==> Performing startup jobs and maintenance tasks
==> Starting application with user 0 group 0
Welcome to Uptime Kuma
Node Env: production
Importing Node libraries
Importing 3rd-party libraries
Importing this project modules
Prepare Notification Providers
Version: 1.9.0
Creating express and socket.io instance
Server Type: HTTP
Data Dir: ./data/
Connecting to Database
SQLite config:
[ { journal_mode: 'wal' } ]
[ { cache_size: -12000 } ]
SQLite Version: 3.36.0
Connected
Your database version: 10
Latest database version: 10
Database no need to patch
Database Patch 2.0 Process
Load JWT secret from database.
No user, need setup
Adding route
Adding socket handler
Init the server
Trace: RangeError [ERR_SOCKET_BAD_PORT]: options.port should be >= 0 and < 65536. Received NaN.
at new NodeError (internal/errors.js:322:7)
at validatePort (internal/validators.js:216:11)
at Server.listen (net.js:1457:5)
at /app/server/server.js:1250:12 {
code: 'ERR_SOCKET_BAD_PORT'
}
at process.<anonymous> (/app/server/server.js:1456:13)
at process.emit (events.js:400:28)
at processPromiseRejections (internal/process/promises.js:245:33)
at processTicksAndRejections (internal/process/task_queues.js:96:32)
If you keep encountering errors, please report to https://github.com/louislam/uptime-kuma/issues
Issue Analytics
- State:
- Created 2 years ago
- Reactions:5
- Comments:9 (5 by maintainers)

Top Related StackOverflow Question
Interesting. @gaby thanks for the highlight. You may be right, I think I found the issue. It’s because of Kubernetes service links.
For Kubernetes users who have their service named
uptime-kuma, Kubernetes service links feature (default) would generate some environment variables, one of which isUPTIME_KUMA_PORT. (Docs: https://kubernetes.io/docs/concepts/services-networking/service/#environment-variables)If we would like to avoid this issue, we should probably validate the value of the environment variable before using it.
For people facing this issue on Kubernetes, either rename the service to something else like
uptime-kuma-webor disable service links for uptime-kuma by settingenableServiceLinks: falsein the Pod spec of the Deployment object.@gaby Nah can’t be blamed. The project belongs to @louislam and he has the freedom to do whatever he wants to the codebase, even if the git branching strategy is not exactly the best practice. Support here is already at his own free time, and that I appreciate.
@louislam I understand that it’s written in the docs there at k8s support is offered by community only. Nonetheless I did not follow the deployment instructions from there and just wrote my own so the problem does not lie with the Kubernetes instructions so I’m not asking for a fix there.
My intention is to put it up here for anyone who faces the same issue.
I’d also like to suggest for stronger validation on accepted values for port in the environment variables, and for a safer fallback such that instead of raising a fatal error in the event of a validation error of the port value, the program may fallback to default value of 3001.