[Feature Request] Option to hide Widget errors for stopped containers. #3103
Replies: 4 comments
|
Thanks for posting a discussion about homepage here on GitHub. Homepage now uses a fancy new AI tool thanks to our friends at Glime, so the answer below is the AI bot's attempt to answer your question. If you feel it's sufficient you can mark the answer and close this post, otherwise feel free to leave it open of course! Thanks for using Homepage! ❤️ To address the issue of service widgets showing a big red API error when the corresponding service (docker container) is offline or exited, you can utilize the To hide the error messages globally, you can add the following to your hideErrors: trueAlternatively, if you want to hide the error messages for a specific service widget, you can add the - Example Service:
...
widget:
...
hideErrors: trueBy setting Please note that as of my knowledge cutoff date, there is no specific global setting that automatically hides API errors only for exited containers. The For now, you can apply the This comment was generated by Glime. |
|
With docker status fields fixed in .service-card:has(.docker-status[title="Exited"]) {
/* Other styling changes for Exited Services */
/* ... */
/* Hide API errors for unavailable Services */
& details {
display: None;
}
} |
|
This discussion has been automatically closed due to lack of community support. See our contributing guidelines for more details. |
|
This discussion has been automatically locked since there has not been any recent activity after it was closed. Please open a new discussion for related concerns. See our contributing guidelines for more details. |
Uh oh!
There was an error while loading. Please reload this page.
Description
Currently any service that is offline (docker container

exited) and has Widgets configured will show a big red API error.As this service is down, the inability to reach its API is expected. For those cases it'd be nice if we could have a global setting that would hide the API error for exited containers.
Other
Currently fumbling with some custom JS implementation, but native support would be preferred.
All reactions