Bring back home-assistant.log for supervised users

[Petro31]

Describe your core improvement

2025.11 removed home-assistant.log if you're a HAOS or Supervised user. I'd like the option to have them back as well as the past log.

Both of these items were necessary for debugging systems through restarts as well as simple configuration errors, like creating a template sensor or a rest sensor.

Current limitations

Debugging just got harder

1. We can't use our own tail software, which typically all use files stored to disk. (No text styling options, highlighting, columns, etc)
2. There is no previous log file to view after a restart or a reboot
3. When only samba share is working, you can't view logs
4. If we use a devorak keyboard, we can only use SSH because the console only supports qwerty.

Technical benefits

• Helps debugging

Additional context

No response

[tomlut]

Link to PR: home-assistant/core#146675

[Mariusthvdb]

for as long as I use HA now, about 9 years, the advise has been to move away from SDCards simply because they will fail. Might take a while, but they will.

considering that, it seems the wrong fix for the problem to take away the log. Especially in a time where more and more users will be installing HA in more robust machines, or in virtual ones, which dont have that issue either?

In the PR there has been a chat about the users choice of en/disabling that log write to disk, and decision was to not do that.
maybe that can still be reconsidered. In which case the whole PR needn't reverted, just amended

[edenhaus]

why introduce such a breaking change (it isnt even marked as a breaking change),

@Mariusthvdb That's not correct. It was marked as a breaking change. See the label, which are the ones that count in the end. The bot will set the correct labels from the PR, when opening the PR.

[Mariusthvdb]

Ok yes I see now

[ScottG489]

I think reducing disk usage and writes are both good ideas, regardless of what hardware you're on. The issue is that doing it this way breaks some users workflows, so we should try to find some ways of maintaining that functionality for those who need it.

[timmo001]

I'd like to suggest a symlink to the logs instead, the config directory is a good place to find everything, it can also be the easier place to diagnose a broken setup. If there are multiple logs avaliable, os, supervisor, network etc. potentially a directory could be used /config/logs/<symlinked to journal>?

---

This is the first I heard of this change, its a good one, but it needs ways of accessing the logs when your system is remote and the UI is down. Unrelated, but the supervisor test endpoint (I can't even remember the port number) observer at :4357 which shows whether the supervisor is up etc, could also give a view/download for the logs

[Mariusthvdb]

just stating it's a good one, is not really appreciative of the reasoning behind this discussion tbh...

the whole point is that OP feels it is Not a good one. as do a few other posters/users

[timmo001]

To clarify, it's not good that logs can't be accessed via /config anymore, which is why I suggested the symlink.

This removes the need to write to the filesystem twice, and gives access to more logs for those only with samba access for example

[ScottG489]

I don't believe the files in /config/logs/ are plaintext: https://www.freedesktop.org/wiki/Software/systemd/journal-files/

Another option might've been the logs from docker in /var/lib/docker/containers/. However, it doesn't look like they log here and instead integrate logging with journald, which is kinda a good thing anyways otherwise we'd have even more duplicate logs.

You're still able to download the log file from Settings > System > Logs > (Download icon in the top right). However, for filesystem operations such as watching the file for changes, it's not adequate. It also isn't a substitute for situations where you only have filesystem access or need the old log file.

[cogneato]

I also appreciate reducing disk writes, but the logs (UI) now mostly help the user looking at them and not the people who ask for them. The file was the last remaining piece that could easily be shared for support.

Could this be an optional file instead? Of course, when a system is already in trouble, you can’t enable what you can’t reach.
Symlink or some other option would be great

The observer (:4357) could be expanded to be more useful in general, but the reply to that has always been that it lacks authentication .

[Petro31]

I'd be good with anything that allows me to access the file. Even potentially an exposed port that offers a file:\\ url. Anything we can use to tail the file. (possibly as a HA supported & maintained addon)

[timmo001]

Just as a side note, I know its not the what is being requested, but you can tail with ha core logs --follow along with other options in the CLI

➜ ha core logs --help  

Allowing you to look at the log output generated by the Home Assistant Core
running on your Home Assistant system.

Usage:
  ha core logs [flags]

Aliases:
  logs, log, lg

Examples:

  ha core logs

Flags:
  -b, --boot string    Logs of particular boot ID
  -f, --follow         Continuously print new log entries
  -h, --help           help for logs
  -n, --lines uint32   Number of log entries to show
  -v, --verbose        Return logs in verbose format

Global Flags:
      --api-token string   Home Assistant Supervisor API token
      --config string      Optional config file (default is $HOME/.homeassistant.yaml)
      --endpoint string    Endpoint for Home Assistant Supervisor (default is 'supervisor')
      --log-level string   Log level (defaults to Warn)
      --no-progress        Disable the progress spinner
      --raw-json           Output raw JSON from the API

[Mariusthvdb]

tbh, I probably dont need the file size sensor on the log file.
It had its merits though as a sudden increase did set off alarms....

Logviewer however still requires that, so is broken now too? Is that already filed in that add-on, or fix in the making?
no issue yet so wrote it up there hassio-addons/addon-log-viewer#217

[dingedan]

Just as a side note, I know its not the what is being requested, but you can tail with ha core logs --follow along with other options in the CLI

Not for me, I'm running the latest version:

ha core logs --help 

Allowing you to look at the log output generated by the Home Assistant Core
running on your Home Assistant system.

Usage:
  ha core logs [flags]

Aliases:
  logs, log, lg

Examples:

  ha core logs

Flags:
  -h, --help   help for logs

Global Flags:
      --api-token string   Home Assistant Supervisor API token
      --config string      Optional config file (default is $HOME/.homeassistant.yaml)
      --endpoint string    Endpoint for Home Assistant Supervisor (default is 'supervisor')
      --log-level string   Log level (defaults to Warn)
      --no-progress        Disable the progress spinner
      --raw-json           Output raw JSON from the API

edit: nevermind. I did not realize that this feature is built into the ssh addon instead of core. Updating the ssh addon gave me this feature as well.

[Petro31]

while we wait https://github.com/Petro31/a-file-logger

[Petro31]

it rotates the log, it brings back the old behavior, the startup of the logging is delayed.

[tschmeltzer]

I ended up using https://github.com/cw-cdz/addon-log-viewer (a fork of the org log-viewer, that also makes the home-assistant.log)
Might look into breaking the log function out, and just have that alone running as an addon.
wasn't sure if a-file-logger rotated the logs, and thought it might not catch things before everything else was up and running.

Have to be honest i have never looked this deep into how HA works, so its a learning experience for me

[tschmeltzer]

Something is actively deleting the home-assistant.log file, and i cannot figure out why or when.

[Petro31]

The logs are removed when HA restarts. I suggest you just use the integration and be done with it.

[ekutner]

The integration is very helpful and very much appreciated but it misses the initial logging of integrations that load before it, which is very problematic for debugging integration, and probably some HA issues.

[CoMPaTech]

Adding to this - as also mentioned in the #beta channel - the 'enable debug logging' for integrations is broken as well. Regardless of which one you put in debug logging, as soon as the user turns it off and it would proceed to download the file - one get's a 404. This is most likely not the intended change for end-users willing to provide feedback

[CoMPaTech]

To add to this - the 'regular' log doesn't mention any of the potential debug either (expected as much though, but still not convenient)

[Petro31]

These should be written up as issues against the beta

[abmantis]

Yeah, this one seems to be a frontend bug. It seems that it is still using the older log API instead of supervisor's one.

[CoMPaTech]

home-assistant/frontend#27732

[abmantis]

Hey 👋 ! Thanks for the feedback @Petro31 .

So, when this was being developed there were discussions about whether or not to implement some way to keep the file around. In the end, the decision was to not have that because there wasn't a clear use-case that was worth the extra complexity of a new setting or something like that. Most of the use cases we thought of could still be handled without the home-assistant.log file.

But feedback is welcome, and if indeed there is a common use-case that now became impossible, we should consider it.

I think most use cases (other than downloading trough HA) would be covered by ha core logs or journalctl. Alternatively, and addon could be made to pipe from journald to a log file (an integration also works, but would miss the first HA startup logs).

But, as always, nothing is set on stone!

[bacco007]

A bit of an unusual use case for me - I was using the log file to monitor potential issues by tracking the number of WARNING/ERROR messages and the change in size of the file. If they exceeded a defined threshold, I'd get a notification that there might be something up with my setup.

Admittedly, there are probably easier ways to monitor and notify now.

[robharman]

Was there architectural discussion around the difficulty in only streaming logs of a certain level?

Defaulting to off, and burying a setting for log-level where people who rely on things like this would look seems like it would be a relatively straightforward fix given that the logging channels are already established and, I assume, relatively easy to hook into given they're sysloggy. 0

[borpin]

It should be a system option. Leave it to the user. having to 'download' the file is just such a pain. I just have the config folder mapped to my Windows device and I can open it when ever I want. Search, filter etc.

[tomlut]

We've also lost access to the home-assistant.log.1 file (easily accessible logs from before the last restart). This was a vital support resource to help people troubleshoot system instability.

[andrewjswan]

You can do ha core logs -n 99999 > /config/logs_logs_logs.log using the SSH addon

What if there are more messages in the log than 99999?

[CoMPaTech]

If it's down you couldn't SSH into it so having the logfile there or not is not helping you. Also numbering the logfile isn't. A there is your answer ... if you can't SSH (because the add-on fails) you can still see the logs in HA. If HA doesn't start at all you have console, where you still have ha core logs do disect? Don't get me wrong, I loved the logfile, but we shouldn't make it a bigger issue than it is. Especially throwing in things that aren't true - if you can access the system (either console or SSH) you still can ha core logs - or - if on console login and journalctl -n 1000 - and as such none of these are 'user' territory anyways right?

[andrewjswan]

If HA doesn't start at all you have console, where you still have ha core logs do disect?

SAMBA has always provided simple and convenient access to the log file, both locally and remotely. This access is no longer available.

[CoMPaTech]

Now that is something worth mentioning (though invalid for startup - if the box breaks, so does samba) - but not having it on SMB (of NFS) for that matter is something noteworthy 👍

[andrewjswan]

Now that is something worth mentioning (though invalid for startup - if the box breaks, so does samba) - but not having it on SMB (of NFS) for that matter is something noteworthy

This is if it breaks completely, SAMBA works even with a broken Supervisor or a broken Home Assistant, it has been tested repeatedly.

[bugbountyguy]

I've got syslog-ng installed on my system which sends over the logs to my monitoring server, which parses these into charts and grafana which allow me for sending alerts + have nice lifetime historical data. The system I've got setup allows me to dissect issues at the log level and send me alerts for anomalies to handle things immediately. As this log file will now no longer exist, I'm curious how I can manually re-enable it to continue my syslog-ng setup so that I don't lose access to a lot of the automation I have setup on my monitoring server.

Also, just my opinion, but something like this shouldn't be forced on the users. I can see the benefits to it as much as I can see the losses to it. Having something like this should have been an 'option' for people to select. Default it not write the log file if preferred, but give folks the option to enable it if they need or want those logs for any reason.

[CoMPaTech]

@bugbountyguy @hadavies for that specific case I'd reckon the request shouldn't be 'bring back the physical log file' but rather 'feature request configuring remote log receiver' to have journald send it directly instead of both journald writing and another process (syslog-ng) reading the same file :) But I have not yet taken a plunge at looking at how HAOS sets it up, but that could be the most beneficial way.

[hadavies]

I've got syslog-ng installed on my system which sends over the logs to my monitoring server, which parses these into charts and grafana which allow me for sending alerts + have nice lifetime historical data. The system I've got setup allows me to dissect issues at the log level and send me alerts for anomalies to handle things immediately. As this log file will now no longer exist, I'm curious how I can manually re-enable it to continue my syslog-ng setup so that I don't lose access to a lot of the automation I have setup on my monitoring server.

Also, just my opinion, but something like this shouldn't be forced on the users. I can see the benefits to it as much as I can see the losses to it. Having something like this should have been an 'option' for people to select. Default it not write the log file if preferred, but give folks the option to enable it if they need or want those logs for any reason.

Completely agree, this should be a choice, because the intention behind it is great but not all use cases have been understood.

What do you use for your log aggregation?

[bugbountyguy]

It's a personal python script/app I wrote years ago to handle all the various types of logs I get across the network. It's a bit dated and may be something I can finally replace these days, but it was at a time when some devices just didn't work with sending json payloads through syslog-ng and required some special parsing that I wanted... I think I should be able to convert that at the server side these days. Data's then all stored into a MySQL database which I run through Grafana for dashboards and metrics.

[LGO44]

A very nice tool, very easy to use, used by many people
Why has it been suppressed? In this flow we can try to find a work around.
It's an add-on , each one is responsible for its use...

[AndersRipa]

Please bring back the log files!
Log files should be readable/accessible without HA up and running!

[AndersRipa]

As of this release, we’ve stopped writing logs to the configuration folder. You can still view and download all logs from the Home Assistant settings page, just like before. We’ve adapted that page to read the logs from the OS directly instead.

Since the logs still are written to disk, how do I read them from a system that does not start?
E.g. from the file system.
What is the format?
What tools are needed?
What is the path to the logs?

Installing something before the crash defeats the purpose of having logs! So that's not really a valid option

[pergolafabio]

As of this release, we’ve stopped writing logs to the configuration folder. You can still view and download all logs from the Home Assistant settings page, just like before. We’ve adapted that page to read the logs from the OS directly instead.

Since the logs still are written to disk, how do I read them from a system that does not start? E.g. from the file system. What is the format? What tools are needed? What is the path to the logs?

Installing something before the crash defeats the purpose of having logs! So that's not really a valid option

Exactly, even the rotation log file is gone.
Please give us log back , or make it an user option at least!

[CoMPaTech]

It's still there ha core log from console :)

[andrewjswan]

It's still there ha core log from console :)

It can't provide a log file for the current Home Assistant startup; it only displays the last couple of lines or all the garbage it has...

[EDelsman]

I have no clue how to get logs from a HAOS that is down. And I guess that applies to 90% of all users.

SSH into it? Isn't that impossible without an addon? This feels like a car that can only open the hood if the engine is running.

Who from those who thought it wise to remove the functionality can we refer all users to to help them out? I won't be able to.

My HA is in a closet, I cannot get it to a monitor and keyboard without unplugging it, ethernet and three usb extension cords with z-wave, zigbee and thread adapters. All my monitors are attached to monitor arms, stuck to a desk. So whatever I can get straight from the console is not what caused HA to crash?

[CoMPaTech]

As replied above to a thread - 'users' wouldn't even know what to do either way - you'd have to tell 'm to "more" or "less" home-assistant.log - which they still can using ha core log. So the user isn't affected, the experienced user might be, but even those can still use that command (or go die-hard and console login to tinker with journald)

[robharman]

Telling a user that they wouldn't know what to do with the tool they're complaining you broke isn't a great approach. Likewise, telling they can do half of what they used to do with twice the effort is not a great way to sell the feature.

ha core log is useful for half of what viewing the log file was, but it's useless for troubleshooting across time, and (as multiple people (HA users) have noted above) for troubleshooting issues where you lack access to the console or the GUI. Such as headless installs in hard to reach places, VMs on headless systems, or for tools which rely on a log to help diagnose issues, which are basically the most primitive and fundamental tool there is for debugging.

Log files always do the same thing, they have repeatable behaviour across tools, they're easy to integrate, they're dead simple to understand. Removing them is the best way to make fixing problems harder. I can pull an SD card from a system and read the log files on a working computer, there's no way to do anything close to that with ha core log, or any of the other proposed workarounds to the removal of the log file .

Spammy log entries are a solved problem, because they're a user preference problem not a system problem. The log entries are already classified into info/debug/error, deciding that none of that should be written to disk is a decision that is going to make debugging everything harder in the long run.

[CoMPaTech]

Hi @robharman - let's clear the air first, I'm at loss as well as I depicted in earlier replies (and even commented on proper communication and handling in the PR). While we all would agree 'having it twice ain't nice' there is considerable impact. Back to the statements I made, some people feel 'how can I help the user' is a thing => that's why I replied on that kind of users. Non-domestic power-users (you, the responders above and me among them) have different needs. Do note that we could enable the 'I know what I'm doing' button on something like the SSH/Terminal add-on and log straight into HAOS and do whatever we want there.

You indicate that executing the log command doesn't work - but how would you even reach (besides the very valid https://github.com/orgs/home-assistant/discussions/1527#discussioncomment-14896239 use-case) said log without it? Also note that you can The SD card is one we can safely chalk up there with SMB and NFS, good point!

On your last comment, they are not 'not' written to disk - just not twice and unfortunately less easy to reach. As said, I also rather 'have it' but there is a lack of options (even with Petro's custom_component). I sincerely hope someone comes up with a clever 'expose' like properly exposing journald and/or remotely syslog-ging thereof but that will require changes to HAOS.

[pergolafabio]

still , i hope can consider you bring the log file back , i always opened it with notepad using smb addon, was extreme usefull when for instance HA itself wouldnt start a while ago
Or make it at least an configurable option to create .log files, let the user decide if they want it or not....

[andrewjswan]

which they still can using ha core log

How do I get the log for the current session? Like in home-assistant.log?
And how do I get the log for the previous session? Like in home-assistant.log.1?

[CoMPaTech]

Let's compile a list of things that the community wants a solution on, without focussing on what's lost or what can be achieved with ha core logs or Petro's custom_component (though some/most might be able with it):

• Filesharing (samba/nfs) @andrewjswan comment
• Inspecting the physical/virtual media @robharman comment
• Access previous/last session log in addition to only the current (i.e. .1 file) @andrewjswan comment
• Log viewer add-on @Mariusthvdb GH issue
• Log tail sensor? @Mariusthvdb comment
• Log period/rotation? Presumably journald cleans after itself where previously the whole 'since start' log was available @andrewjswan comment
• Rapid log growth indication (or similar situation) (i.e. like file size sensor but for other purposes) @MankiniChykan comment
• Ability to see 'since started' has also vanished @andrewjswan @CoMPaTech comment as you can't request beyond Uint number of lines - understandably with log rotation but still start issues could be relevant?

In his reply abmantis already indicated use-cases help get a other/proper route (https://github.com/orgs/home-assistant/discussions/1527#discussioncomment-14831724)

[andrewjswan]

access the current (with limitations) through the logs command

We currently have access to all log entries for the entire storage period, without breaking them down into current, previous, or previous week. Or, if there are a lot of errors, we don't have access to the full log for the current session (I understand there's a limit on the number of entries).

[MankiniChykan]

file size sensor

I second the file size sensor for the log file. It is a good indicator for when things are going astray. (Rapidly increasing there is a problem)

[MankiniChykan]

Thanks for adding so quickly @CoMPaTech

[MankiniChykan]

Does resetting HA now clear the log like it did previously?

[CoMPaTech]

Does resetting HA now clear the log like it did previously?

Tested on and with a couple of nines it still produces Oct 26 (even after restarting either core or the VM)

[pergolafabio]

if i do "ha core logs" , i get below, whats that for garbage? completely useless ??

[Mariusthvdb]

Tbh, that has been in de logs before opening the log from within the Ui

[frenck]

if i do "ha core logs" , i get below, whats that for garbage? completely useless ??

So... we collaborate in this environment. Just saying that the tone could be slightly different in your response there.

Anyway, this is a feature request, not an issue tracker. If you are experiencing an issue, I would recommend to raise on in the CLI issue tracker so it can be looked at.

Thanks! 👍

../Frenck

[CoMPaTech]

For people later to this longer thread; see the comment on the PR here https://github.com/orgs/home-assistant/discussions/1527#discussioncomment-14831724 or my suggested list of users chiming their alternatives https://github.com/orgs/home-assistant/discussions/1527#discussioncomment-14899460 Happy to add new ideas to the list if you have them (but I've not seen newer ideas, though one never knows if someone has another lightbulb moment).

For those impatient for (or if) any changes you can use Petro's workaround https://github.com/orgs/home-assistant/discussions/1527#discussioncomment-14829700

[pergolafabio]

For people later to this longer thread; see the comment on the PR here https://github.com/orgs/home-assistant/discussions/1527#discussioncomment-14831724 or my suggested list of users chiming their alternatives https://github.com/orgs/home-assistant/discussions/1527#discussioncomment-14899460 Happy to add new ideas to the list if you have them (but I've not seen newer ideas, though one never knows if someone has another lightbulb moment).

There is only 1 option, revert the change, there were no people complaining, we don't need add-ons or fancy commands or UI , we just need the file like it was

[CoMPaTech]

There are multiple, I've amended to add Petro's comment

[Petro31]

Can you please stop spamming this FR with AI crap?

The custom integration I wrote literally brings back the log to file functionality exactly the way it was before. The only difference is that it loads through the custom integration process, which means it loads some time later than it used to. There are no other differences.

[HelixX23]

the braking change was made here
home-assistant/core@07da0cf

[pergolafabio]

@Petro31 can you give me your 24/7 telephone number, so if there is a problem with my system not booting i can call you to fix it for me? i already have had so many headaches with HA in the past running forst on RPi SD Card, then on IntelNUC now on Proxmox. i dont want to be forced into a corner because someone removed my logfiles because of nothing.

Just stop with that AI shit and pointing to breaking changes links, we are aware of that

[CoMPaTech]

That is really uncalled for Helix, we get you are upset, you are not alone. Petro created a workaround (how nice of him to do that, right?).

[Petro31]

yes, how nice for him to do that in advance of the braking change. somehow he knew this will blow up quickly

the community made so many suggestions in doing it right. for example catching the sd card installations and turning log files off only on them... but now we are all affected

and yes, so "shit" that an AI can find the spot where it fails and quickly can produce patches for it

I made the integration because I was upset that the log file was removed. I found out during beta and made it because I knew how to get the log file back. I did not make the change that removed the log file, so don't direct your nastiness in my direction. Grow up.

[frenck]

Hey everyone 👋

First off, thank you to everyone who took the time to share their use cases and workflows. This kind of detailed feedback is genuinely valuable and helps us understand how people actually use Home Assistant in ways we might not have anticipated.

I want to let you know that we hear you, and we're actively exploring options. Nothing concrete to announce just yet, but the feedback in this thread (and the well-documented use cases) is being taken seriously.

That said, I do want to take a moment to talk about something else I noticed in this thread.
We're all here because we care about Home Assistant. The people who contributed the original change care. The people who are frustrated by it care. The maintainers responding care. We're all working toward the same goal: making Home Assistant better for everyone.

Open source thrives on collaboration, and that means we iterate together. Sometimes changes don't land perfectly the first time, or pan out to kill others use cases. That's okay. That's part of the process. What matters is that we can have constructive conversations about it and find solutions together.

What doesn't help is when frustration turns into dismissiveness, assumptions about intent, or responses that shut down dialogue rather than open it up. I've seen some of that in this thread, and I'd like to gently remind everyone that we can disagree, we can be frustrated, we can advocate strongly for our needs, all while still treating each other with respect.

We're a community. Let's act like one.

More updates to come as we work through the options. In the meantime, thanks for your patience and for continuing to help make Home Assistant what it is.

../Frenck

                       

Blogging my personal ramblings at frenck.dev

[frenck]

Again, we are exploring options, as stated above.

Then why you didn't start with exploration before you have got rid of critical functionality?

@michalk-k Can you please read my original post here? Thanks! 👍

[michal-bartak]

Frenck, I appreciate that you stepped in to communicate here. But—please don’t take this the wrong way—I hear similar statements almost every day in corporate environments. It often feels like there is a duty to say “we all care,” yet the actual questions and doubts remain unanswered. The underlying message becomes: you (the users) simply have to accept it. Please take this as constructive feedback.

I still didn’t find an answer to my question in your original post. Logs are critical for maintaining a server-like service—we can agree on that. They must remain easy to process with external tools, even if the system is completely down. System administrators rely on text processing, regex, and similar tools every day.

With that in mind: why wasn’t there an exploration of options—or even a simple use-case survey within the community—before making this change? I’m not asking to assign blame; I’m trying to understand what happened. Were the decision-makers really that confident nobody relies on textual logs? And why are you guys refusing to return the logs until a satisfying alternative is developed?

The only argument provided so far is storage wear. But with respect, this hasn’t been a real concern for the past decade, even in the micro-SSD era. Any serious HA setup uses SSD storage. Wear is simply not a practical issue anymore.

We can’t find a good solution without acknowledging all motivations and all use cases. And right now, the community still doesn’t know what justified this change.

By the way, you wrote:

Every change affects someone; we do our utterly best, in any way we can, to ensure we take into account the 99% of use cases. We have to accept that we can never reach 100%, and that is fine, as long as we keep talking about things :)

Again, this sounds like a generic corporate response—one that is hard to argue with because it’s true in a very abstract sense, but doesn’t address the concrete issue. Why change something in a way that likely reduces the number of satisfied users? Were there users who were actually bothered by the existence of a textual log? And if so, is accommodating them worth the risk of leaving HA instances without the most universal and reliable troubleshooting tool we have?

[gcoan]

I too miss the logfile and found it was useful to be able to view it via a Samba share.

That said, architecturally writing the same information in two places is bad practice (no single version of the truth) so I can see why the change was made.

I suggest we have to trust @frenck and the developers to take on board the feedback and iterate in future releases. We also have to trust them to represent our many, varied and conflicted views and deliver the enhancement pipeline.
It’s simply not practical for every single concept, change or enhancement to be designed, developed and tested by committee.

That’s why we have Product Owners, to steer and direct the product. We can give them feedback and our thoughts but ultimately they decide the direction and what the definition of done is.

[frenck]

Again, this sounds like a generic corporate response

This is where my responses end. I've been everything but coperate, I'm being honest and open on the current state and views, taking the time to answer as open and honestly. To me, this kinda felt offensive to read. You want answers, I get it, I've been very and extremely clear on that one: We are looking into options. Have some patience and give me/us the opportunity to come up with some.

../Frenck

[pergolafabio]

well @frenck the problem is , if HA doesnt start, you cant access the log section anymore in UI
now you will say, you can use command line ... but what if you dont have the SSH addon installed?
The only solution is then attach a screen and keyboard and access console? thats not an easy thing ...

The log file was there for troubleshooting, but now its gone and there is no way to troubleshoot an HA start issue

Make the log file an optional thing, so users can still decide if they want it or not ...

[frenck]

Honestly, there are solutions for that in place. The terminal provided by the OS provides these tools as well, and the build in SSH for debugging purposes can be enabled using an USB stick is needed.

That said, the point has been raised above already, so let's not run in circles and start repeating all cases. The points are clear, and as stated above: we're actively exploring options.

../Frenck

                       

Blogging my personal ramblings at frenck.dev

[ekutner]

We're talking about software, there are always work around, I can also monkey patch the code to write the logs. That is not the point. The point is that there is a standard and very very easy and convenient way to monitor a system using log files. It's just easy, it works, and it had worked for 50 years. What greater purpose is served by stopping it?

[frenck]

The point is that there is a standard and very very easy and convenient way to monitor a system using log files.

systemd journald is just that... Which is what is now used.
Like it our not, it is not something exotic 😉

But, circling back, we've heard your feedback, and are actively exploring options.

../Frenck

                       

Blogging my personal ramblings at frenck.dev

[jarrah31]

I genuinely would like to know where and how I can use systemd / journald (journalctl?) to view HA logs in HA OS please? Happy for someone to point me in the right direction?

I've looked in the following locations with no luck so far:
https://www.home-assistant.io/docs/configuration/troubleshooting/
https://www.home-assistant.io/integrations/logger/#viewing-logs
https://www.home-assistant.io/docs/troubleshooting_general/
https://www.home-assistant.io/common-tasks/os/#home-assistant-via-the-command-line

I guess it needs access to the base Linux CLI rather than via the SSH add-on (journalctl isn't available via the add-on's SSH access)? If so is it possible to do this remotely without terminal access, and are there any official guides on how to do this please?

[frenck]

Good point! There is some docs you pointed out that needs adjusting 👍

As for the viewing, we provide a view through the UI, of course, and the ha command line will provide tooling as well:

➜ ha core logs --help  

Allowing you to look at the log output generated by the Home Assistant Core
running on your Home Assistant system.

Usage:
  ha core logs [flags]

Aliases:
  logs, log, lg

Examples:

  ha core logs

Flags:
  -b, --boot string    Logs of particular boot ID
  -f, --follow         Continuously print new log entries
  -h, --help           help for logs
  -n, --lines uint32   Number of log entries to show
  -v, --verbose        Return logs in verbose format

Global Flags:
      --api-token string   Home Assistant Supervisor API token
      --config string      Optional config file (default is $HOME/.homeassistant.yaml)
      --endpoint string    Endpoint for Home Assistant Supervisor (default is 'supervisor')
      --log-level string   Log level (defaults to Warn)
      --no-progress        Disable the progress spinner
      --raw-json           Output raw JSON from the API

Besides that, if you are familiar with journald's tooling, you can of course use that as a reference as well 👍

../Frenck

[frenck]

Oh hi there 👋

We are currently looking at the options to resolve the raised requests in this topic. To prevent further tension and constant circling around the same topics/use cases, I've temporarily locked down this topic / feature request until we are ready to more forward more concretely.

Thanks for your patience on this one 👍

../Frenck

                       

Blogging my personal ramblings at frenck.dev

[abmantis]

Hey!
Just wanted to let you all know that in the next release of Home Assistant (2026.01) you will be able to enable the log file again!
For that, you just need to enable to option using the Home Assistant CLI:

ha core options --duplicate-log-file=true
ha core rebuild
ha core restart

This needs to be done only once and is permanent (unless you set it back to false).

I hope this address the concerns and use cases that were raised in this discussion.

[Petro31]

You need to update the addon, supervisor, and HA. If that's the custom addon, it may not be updated yet.

supervisor and HA are : 2026.01.0 Addon is also up to date:

Advanced SSH & Web Terminal Current version: 22.0.3

Advanced SSH & Web Terminal is the custom one

[MirandaPoth]

@Petro31 I'm running HA OS on bare metal (a NUC) and want to use this feature to get my logs back. Do I need Advanced SSH & Web Terminal instead of the usual Terminal & SSH please?

[pergolafabio]

you need this one, Terminal & SSH9.22.0, here is the CLI updated,, in the advanced one, (community edition) , is still using old CLI

[Petro31]

No, the Terminal & SSH addon has the update to run the code. That's the only addon you need. Or you can plug in a keyboard and monitor to your NUC.

[MirandaPoth]

Perfect, thanks guys. I have my log file :-)

[pergolafabio]

Many thnx!!! Is this a persistent option across updates?

Will it also make the old _1 file back? Was usefull too

[Petro31]

Yes, its done at the supervisor level.

To clarify, the CLI modifies the start up params. So this comment may not be technically correct, however the "yes" is correct.

[HelixX23]

Nice 🙂👍

[HelixX23]

Thank you very much and sorry for the inconvenience.

[hovant]

Absolutely great, thanks a lot

[Mariusthvdb]

For that, you just need to enable to option using the Home Assistant CLI:

ha core options --duplicate-log-file=true

haha, that duplicate brought a smile to my face ;-)
there is a certain amount of 'we told you so' in that option...

but besides that, great you considered and decided.

Thank you very much, appreciated.
(hope this will also make the Logviewer add-on work like before)

[shamaniThrall]

in core 2025.12.4 it says
Error: unknown flag: --duplicate-log-file

its realy annoying.. i have waiste 2h now to get the log viewer working again but still no progress.

[robharman]

The feature is planned for the next release, it is not present yet.

The good news is that you're probably setup correctly for when it does land, so you don't need to waste any more of your time looking for information that's easily available rather than spending hours working on something that's unavailable.

[mccaffm]

still not available, even though docs state its valid

??

`➜ ~ ha core options --duplicate-log-file=true
Error: unknown flag: --duplicate-log-file
Usage:
ha core options [flags]

Aliases:
options, option, opt, opts, op

Examples:

ha core options --backups-exclude-database=true

Flags:
--audio-input string Profile name for audio input
--audio-output string Profile name for audio output
--backups-exclude-database[=false] Backups exclude Home Assistant database file by default
--boot Start Core on boot (default true)
-h, --help help for options
--image string Optional image
--port int Port to access Home Assistant Core (default 8123)
--refresh-token string Refresh token
--ssl Use SSL
--watchdog Use watchdog (default true)

Global Flags:
--api-token string Home Assistant Supervisor API token
--config string Optional config file (default is $HOME/.homeassistant.yaml)
--endpoint string Endpoint for Home Assistant Supervisor (default is 'supervisor')
--log-level string Log level (defaults to Warn)
--no-progress Disable the progress spinner
--raw-json Output raw JSON from the API

Error: unknown flag: --duplicate-log-file`

[Petro31]

You have to use the latest version of the official ssh addon

[mccaffm]

AH, so it dont work with Advanced SSH & Web Terminal 22.0.3, im not sure i understand why, but i can accept that . thanks

…

________________________________ From: Petro31 ***@***.***> Sent: Saturday, January 24, 2026 10:39 To: home-assistant/feature-requests ***@***.***> Cc: Mike McCaffery ***@***.***>; Comment ***@***.***> Subject: Re: [home-assistant/feature-requests] Bring back home-assistant.log for supervised users (Discussion #1527) You have to use the latest version of the official ssh addon — Reply to this email directly, view it on GitHub<#1527 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADSXK4WXQY6EDIRGORBIP5D4INDX3AVCNFSM6AAAAACKTA24ISVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKNJZGAZTONQ>. You are receiving this because you commented.Message ID: ***@***.***>

[zweckj]

closing this as implemented