To Reproduce
- Deploy any service whose logs emit a line like
... failed: false, ... error: none (e.g. an ofelia scheduler sidecar).
- Open the service logs in Dokploy.
- The successful line is displayed as an error (red).
Current vs. Expected behavior
The log viewer colors lines red ("error") based on keyword regexes in getLogType, but the patterns match the key and ignore the value. Any line containing error: or the word failed is flagged as an error even when it explicitly reports success — e.g. error: none and failed: false.
This is common with schedulers/cron tools. Example from ofelia, whose job-completion summary is a fixed format:
2026-06-02T09:34:01.443Z common.go:125 ▶ NOTICE [Job "sync-1m" (e1305c5b54b1)] Finished in "326.16795ms", failed: false, skipped: false, error: none
This is a successful run (failed: false, error: none), yet it renders red.
Both fire on the line above regardless of the value that follows. Because classification is purely keyword/content-based, a real failure (failed: true, error: <msg>) produces the identical "error" styling — so the level conveys no signal for these lines.
Expected behavior
A line stating error: none / failed: false should not be classified as an error. The classifier should consider the value following the key (e.g. treat error: none|null|false|0|"" and failed: false as non-errors), and/or fall back to the container's stdout/stderr stream or the embedded log level rather than substring keyword matching.
Provide environment information
- Dokploy: v0.29.5
- Linux Debian 13
Which area(s) are affected? (Select all that apply)
Docker Compose
Are you deploying the applications where Dokploy is installed or on a remote server?
Remote server
Additional context
In the ERROR regex block, require a non-trivial value after the key, e.g. exclude error:\s*(none|null|false|0|-|""|'') and failed:\s*(false|0|no) before classifying as error. Optionally honor the riginal Docker stream/level when the content is ambiguous.
apps/dokploy/components/dashboard/docker/logs/utils.ts -> getLogType.
The ERROR branch matches on:
/(?:^|\s)(?:error|err):?\s/i // matches "error:" in "error: none"
/\b(?:exception|failed|failure)\b/i // matches "failed" in "failed: false"
Will you send a PR to fix it?
Maybe, need help
To Reproduce
... failed: false, ... error: none(e.g. an ofelia scheduler sidecar).Current vs. Expected behavior
The log viewer colors lines red ("error") based on keyword regexes in
getLogType, but the patterns match the key and ignore the value. Any line containingerror:or the wordfailedis flagged as an error even when it explicitly reports success — e.g.error: noneandfailed: false.This is common with schedulers/cron tools. Example from ofelia, whose job-completion summary is a fixed format:
This is a successful run (
failed: false,error: none), yet it renders red.Both fire on the line above regardless of the value that follows. Because classification is purely keyword/content-based, a real failure (
failed: true,error: <msg>) produces the identical "error" styling — so the level conveys no signal for these lines.Expected behavior
A line stating
error: none/failed: falseshould not be classified as an error. The classifier should consider the value following the key (e.g. treaterror: none|null|false|0|""andfailed: falseas non-errors), and/or fall back to the container's stdout/stderr stream or the embedded log level rather than substring keyword matching.Provide environment information
Which area(s) are affected? (Select all that apply)
Docker Compose
Are you deploying the applications where Dokploy is installed or on a remote server?
Remote server
Additional context
In the ERROR regex block, require a non-trivial value after the key, e.g. exclude
error:\s*(none|null|false|0|-|""|'')andfailed:\s*(false|0|no)before classifying as error. Optionally honor the riginal Docker stream/level when the content is ambiguous.apps/dokploy/components/dashboard/docker/logs/utils.ts->getLogType.The ERROR branch matches on:
Will you send a PR to fix it?
Maybe, need help