`--log-level` flag doesn't behave as [originally/incorrectly] assumed on `ha core logs`

[michaelmelody91]

Describe the problem

When running a command such as:

ha core logs --log-level=ERROR
ha supervisor logs --log-level=WARNING

the flag is silently ignored, all log entries are returned regardless of severity.

Example Command and Response

ha supervisor logs --log-level=ERROR
2026-05-19 09:27:44.620 INFO (MainThread) [supervisor.api.middleware.security] /core/info access from a0d7b954_ssh
2026-05-19 09:28:02.494 INFO (MainThread) [supervisor.api.middleware.security] /core/logs access from a0d7b954_ssh
2026-05-19 09:28:54.568 INFO (MainThread) [supervisor.api.middleware.security] /supervisor/logs access from a0d7b954_ssh

Debug information

1. SSH App type

• Community
• Core
• Custom

2. Version of the CLI

ha cli info
update_available: false
version: 2026.05.0
version_latest: 2026.05.0

3. Version of Home Assistant Core & the Home Assistant Supervisor

Home Assistant Core: 2026.5.1
Home Assistant Supervisor: 2026.05.0

4. Output from executing the command with debug info

e.g., ha hardware info should be run as ha --log-level debug hardware info

Provided above

On review of the suggested command above, I'm questoning whether --log-level is as I originally assumed it was to be used. The above leads me to believe its the log level of the CLI itself, rather than the output for ha core|supervisor logs

Expected behavior

As stated above, my assumption was that log-level would control the output of logs returened on ha .. logs. On review of the flag being a Global Flag, I believe my assumption was incorrect.

Rather than a bug (if indeed it's not a bug), would the maintainers be open to a new flag as a feature (or re-using the existing flag in some form)? I'm open to driving any enhancement myself.

The alternative to this enhacement would be that the consumer of the logs (client-side) is responsible for filtering as part of any scripting/log consumption.

My use-case is that I wish to on a daily basis, fetch only errors or warnings from the previous 24 hours. By using a log-level flag, I could return a much smaller subset of logs to be parsed. Similarly, to help in this endeavour, new flags such as --from DATETIME and --to DATETIME would also greatly help. [I realise this bug report has now become a feature request 😄 ]

[michaelmelody91]

Another alternative is that I reduce the log level from HA itself so that I can grab all logs, without the need to filter out DEBUG/INFO etc

[agners]

The flags name is confusing indeed, maybe we'd name it differently, like maybe --cli-log-level.

As for the log filtering: Currently log messages are largely treated as a stream of text which we get from the backend (systemd journald). We don't know the log level for each message, and it also isn't stored in systemd journald. We could rely on a particular formatting, but this seems brittle.

To have more metadata, including log level, in systemd journald we'd have to avoid going through stdout/stderr but instead directly write logs to systemd journald. We have a task (home-assistant/operating-system#4121) and a prototype (home-assistant/operating-system#4121) which implements this for Supervisor, but the effort stalled. With that, we could then correctly filter log messages based on proper metadata.

[michaelmelody91]

Thanks for the feedback @agners 🤝

Agreed on the brittleness point. For my own learning, I'll review the task and associated prototype - I may be able to solve my use-case in another manner, irregardless I might try to pick up the work tha already took place.

Feel free to close or repurpose this issue as as you see fit.