-
Notifications
You must be signed in to change notification settings - Fork 33
Troubleshooting Guide
This guide helps you diagnose Nutify issues quickly using symptom-based checks. It is designed for operators who need fast recovery steps.
Use this sequence every time:
- identify the visible symptom
- run quick checks in order
- apply the smallest safe fix
- validate on UI and target behavior
Before deep debugging, check these five points:
- Nutify service/container is running.
- Login works and dashboard opens.
- Active target in TopBar is the one you are testing.
-
System -> Advanced -> NUT Managershows expected target inventory. -
System -> Logshows no critical recurring errors.
Typical signs:
- browser cannot load
http://<host>:5050 - timeout/connection refused
Quick checks:
- confirm container/process is running
- confirm port
5050is exposed and free - inspect runtime logs
Fix path:
- restart stack/process
- resolve port conflicts
- verify compose path and active compose file are the expected one
Typical signs:
- Next button does not move forward
- validation blocks save/test
Quick checks:
- all required fields are filled
- selected topology matches selected connection details
- target test passes before save
- display name vs UPS identifier are not confused
Fix path:
- correct missing/incompatible fields
- retest target
- proceed only when validation is green
Typical signs:
- configuration save error
- restart step fails
Quick checks:
- open logs and find the first backend error message
- verify NUT config values generated by wizard are valid
- verify no invalid value type was submitted in critical fields
Fix path:
- fix the first error shown in logs (not downstream errors)
- rerun test + save sequence
- rerun restart only after clean validation
Typical signs:
- target card shows disconnected/offline
- data not refreshing for one target
Quick checks:
- verify host, port, UPS identifier (
ups@hostlogic) - verify monitor username/password
- verify remote NUT server health
- verify network/firewall path
- run
poll nowfrom NUT Manager
Fix path:
- correct connection details
- re-enable target if disabled
- retest connectivity and check topbar switching
Typical signs:
- topbar target changes but charts look unchanged
- timezone or currency appears inconsistent
Quick checks:
- confirm active target in TopBar before opening page
- confirm target-specific PowerFlow settings are correct
- refresh page after target switch to confirm data context
Fix path:
- correct target-specific settings in PowerFlow
- verify you are not reading cached expectations from previous target
Typical signs:
- displayed times look shifted
- costs look in wrong currency context
Quick checks:
- open target-scoped PowerFlow for active target
- verify target timezone and currency values
- switch to another target and compare values to confirm per-target scope
Fix path:
- set correct values per target in PowerFlow
- validate by reloading a chart page and checking labels/tooltips
Typical signs:
- event happens but no mail/ntfy/telegram/webhook message
Quick checks:
- Provider channel exists and is enabled in
System -> Provider - provider test action succeeds
- provider is attached to target in
Settings -> Notify - target scope is correct (you are editing the right active target)
Fix path:
- repair provider credentials or endpoint
- reattach provider in target Notify config
- trigger a test event and recheck delivery
Auth-less SMTP:
- leave both Username and Password blank
- set an accepted From Email address
- confirm the saved config appears in the event row selector
Webhook:
- provider Test validates transport only
- real delivery also requires that provider on the target Event Matrix row
- do not use legacy provider-level
notify_*fields
Typical signs:
- report scheduler seems active but no report arrives
- on-demand report fails
Quick checks:
- provider channel for report delivery is valid
- reporter config is saved for correct target
- schedule window/time settings are valid
- logs show no report generation exception
Fix path:
- fix channel config first
- rerun on-demand report once
- then validate scheduled delivery on next run
For long windows, use the built-in rolling presets. Last 7 Days, Last 30 Days, and Last 12 Months use target-local time and optimized rollups.
Typical signs:
- click appears ignored
- navigation only changes after manual refresh
Quick checks:
- verify current page URL and active route
- hard refresh browser once
- check browser console for runtime JS errors
- test in second browser to rule out extension/cache effects
Fix path:
- clear browser cache and retry
- restart frontend/backend process if runtime asset mismatch is suspected
Typical signs:
- target saved in manager but not visible/switchable in UI
Quick checks:
- target is enabled
- target has valid connection details
- one target is marked primary/default as expected
- reload dashboard after save
Fix path:
- enable target and validate connection
- verify manager save succeeded
- reopen dashboard and confirm topbar inventory
Typical signs:
- auto-detect finds no device
- local target test fails with device access issues
Quick checks:
- host sees the UPS device
-
/dev/bus/usbexists inside the container - startup logs include
USB runtime access configured for device group GID ... - no other service holds exclusive access to the UPS
Fix path:
- use the base Compose USB mapping; do not add privileged mode or host
/dev - if automatic group detection fails, set
NUTIFY_USB_GIDto the numeric group owning the host USB node and recreate the container - never use GID
0; assign the UPS to a dedicated host udev group with mode0660when its node is owned byroot:root - use the optional hardware override only for a stable serial/non-USB path
- use host NUT + Network Client mode when Docker cannot expose Linux USB devices
- stop conflicting UPS service on host if needed
- retry auto-detect and then manual fallback if needed
Typical signs:
- auth denied despite expected credentials
Quick checks:
- confirm username/password correctness
- verify auth bypass flags are not unintentionally set
- confirm you are opening the correct instance
Fix path:
- use Forgot Password and prove access with the persistent runtime
SECRET_KEYfrom.env - keep auth enabled for normal operation
- for OIDC failures, open
/auth/login?local=1, then verify exact issuer, callback URI, authorized groups, and username collisions using the OpenID Connect SSO Guide
Typical signs:
- a short query failure appears as repeated
COMMBAD/COMMOK -
ONBATTorLOWBATTappears while NUT still reportsOLorOL CHRG
Current Nutify debounces communication failures per target and only applies a
numeric low-charge fallback while NUT explicitly reports On Battery. If false
events persist, capture consecutive polling logs, raw ups.status, active target,
and exact event timestamps. Do not treat battery.charge.low as current charge.
Quick checks:
- proxy forwards
Host,X-Forwarded-Host, andX-Forwarded-Proto - proxy supports WebSocket upgrade for Socket.IO
- public origin is listed exactly in
SOCKETIO_ALLOWED_ORIGINSwhen required
Wildcards are rejected. Nutify falls back to authenticated HTTP snapshots every five seconds while Socket.IO is unavailable.
If logs contain snmp_open: Unknown host (auto), the SNMP endpoint is missing.
Select snmp-ups, enter the UPS hostname/IP in UPS Host/IP, and verify
ups.conf contains port = "<UPS address>". auto is only valid for local
device drivers. Local NUT Server Address is not the UPS address.
Check selected security level and matching fields:
-
noAuthNoPriv: security name only -
authNoPriv: security name, auth protocol, auth password -
authPriv: auth fields plus privacy protocol and privacy password
Also confirm Docker uses /usr/lib/nut/snmp-ups, endpoint access is allowed, and
the UPS supports the chosen protocol algorithms.
Always capture:
- exact symptom and timestamp
- active target and scenario (single/multi)
- one screenshot of UI state
- relevant log excerpt (first real error, not only follow-up noise)
- recent change done before failure
Use this template when opening an issue:
Environment: Docker + image tag/version
Profile: Single/Multi
Topology: <selected topology>
Symptom: <what is failing>
Expected: <what should happen>
When started: <date/time>
Recent changes: <what changed before issue>
TopBar active target: <target name>
Logs (first error): <paste>
Tried already: <checks/fixes performed>
- keep provider catalog clean and tested
- keep target naming consistent
- verify TopBar target before any save
- backup DB/config before major changes
- validate one change at a time
- Main + Topbar + Multi-UPS Guide
- Multi-UPS Monitoring Guide
- Sidebar Data Pages Guide
- Reports and Notifications End-to-End Guide