uptime-kuma parser is not working correctly after version 2.2.1

[Nirzak]

Describe the bug
When using uptime kuma on non docker environment it's not parsing the log correctly. All login failure logs are getting unparsed

To Reproduce
Install uptime kuma traditionally or point the docker environment uptime kuma logs to a bind mount path.
then add the following config to read the logs from the file

filenames:

• /var/log/uptime-kuma/uptime-kuma-error.log
  labels:
  type: uptime-kuma

Expected behavior
It should parse the login failure logs correctly. For example: my login failure logs are like in the following pattern
2026-03-24T20:48:03+06:00 [AUTH] WARN: Incorrect username or password for user testuser. IP=ip

but after I am running cscli collection inspect timokoessler/uptime-kuma

I have seen that it's completely getting unparsed.

Screenshots

Additional context
Later I have seen that newest version of uptime kuma (2.2.1) is actually producing logs that are hard coded ansi colors which appears if we check the log with less command instead of tail command

ESC[36m2026-03-24T22:22:35+06:00ESC[0m [ESC[38;5;208mAUTHESC[0m] ESC[33mWARN:ESC[0m Incorrect username or password for user thisistest. IP=IP

So after handling the escape ansi colors on the grok pattern it's working correctly.
So this is a issue for both docker and non docker environment actually.

[Nirzak]

Later I have seen that newest version of uptime kuma is actually producing logs are hard coded ansi colors which appears if we check the log with less command instead of tail command

ESC[36m2026-03-24T22:22:35+06:00ESC[0m [ESC[38;5;208mAUTHESC[0m] ESC[33mWARN:ESC[0m Incorrect username or password for user thisistest. IP=IP

So after handling the escape ansi colors on the grok pattern it's working correctly.

[Crash1602]

I just updated my Uptime Kuma to version 2.2.1 and noticed that not a single failed login entry is being parsed. I have plenty of incorrect login attempts, but all 186 lines are marked as unparsed. I’m using the Docker container and ingesting stdout, but I’m seeing the same issue.

Is there already a PR to adjust the grok patterns so this can be fixed?

@LaurenceJJones I’ve mentioned you here because you’re always a big help 🙂

[LaurenceJJones]

I don't work for CrowdSec anymore, if you debug its the timestamp open a PR and the team will get round to merging it.

Just ensure you add:

• test log lines that have a new timestamp
• regenerate the assert files so we can test previous logs and the new logs.

[Crash1602]

Thank you for the quick reply, I really appreciate it, especially since you're no longer with CrowdSec.

I'm not the right person to create a pull request, but your comment about the timestamp should certainly help others who know how.

[Nirzak]

I just updated my Uptime Kuma to version 2.2.1 and noticed that not a single failed login entry is being parsed. I have plenty of incorrect login attempts, but all 186 lines are marked as unparsed. I’m using the Docker container and ingesting stdout, but I’m seeing the same issue.

Is there already a PR to adjust the grok patterns so this can be fixed?

@LaurenceJJones I’ve mentioned you here because you’re always a big help 🙂

Hi I have described the issue above. Uptime Kuma has enforced ansi colors on logs after their v2.2.1 update. So unfortunately the only way is design a ugly grok pattern which can escape dynamic ANSI charactera like this ESC[36m

the main log with the ansi characters are like this ESC[36m2026-03-24T22:22:35+06:00ESC[0m [ESC[38;5;208mAUTHESC[0m] ESC[33mWARN:ESC[0m Incorrect username or password for user thisistest. IP=IP

[Nirzak]

Mentioning @timokoessler as the original developer of the parser
Thanks

[LaurenceJJones]

Ahh before I left I did create this pr which is why I made it 😆 I forgot initially.

There is a conflict within the tests but maybe if you guys comment or push, the team could evaluate adding it as we dont really want to add ansi escape sequences to the grok pattern and would rather strip it using the helper I made.

or if the team doesnt want it then yes, the grok pattern would either need to be less strict and skip over them but its meeeh cause if uptime kuma changes it then creates another grok pattern update.

[LaurenceJJones]

backlink for team #1430

[Crash1602]

Perhaps these comments alone will help the team become aware of the problem and actively address it. I'm surprised that so few users are reporting it, since Uptime Kuma is widely used, as is CrowdSec :-)