Dokploy
Log viewer incorrectly displaying error log level when error log level is not used
To Reproduce
My guess is it's doing this because the log message includes the word "failed" in it.
Here's my evidence from Dokploy log viewer:
You can see the red coloured line displays as an error.
However, the java code for this message uses log level info. Additionally, I've cross-refenced this log in Grafana and it displays correctly in that. See below Java code and Grafana logs screenshots.
Current vs. Expected behavior
Currently a log with level info have the word "failed" in its message displays as an error log in the Dokploy log viewer.
It should display as log level info, regardless of what words exist in its log message.
Provide environment information
Not relevant in this case, but,
Dokploy Cloud
Hetzner
amd64, 4 CPU, 8GB RAM
Debian 12
Docker Compose running Java Spring Boot service with JRE 17
Which area(s) are affected? (Select all that apply)
Cloud Version, Docker Compose
Are you deploying the applications where Dokploy is installed or on a remote server?
Remote server
Additional context
My guess is it's doing this because the log message includes the word "failed" in it.
Will you send a PR to fix it?
Maybe, need help
Looks like it's caused by this line https://github.com/Dokploy/dokploy/blob/9c19b1efa33be896bcb85bfd398dd69c128b7a5e/apps/dokploy/components/dashboard/docker/logs/utils.ts#L90
Not sure this is an easy fix for me, as I'm unaware of your preferred approach here, and the current logic looks like it doesn't try to evaluate the actual log level from the log output, but rather tries to determine it from the message content.
That's right, it tries to parse the message and based on the content it shows the log type, I don't know if there is a simple way to do this, I'm open to suggestions.
I encountered this recently with a similar false positive. My suggestion would be:
- First check for explicit markers ([INFO], ERROR:, etc.)
- Then use more conservative content-based patterns
- Remove broad keyword matching (like /\bfailed\b/)
- Default to info for ambiguous cases
I have proposed my approach to solving this problem in this PR #3070 . Please feel free to let me know what you think.
