Troubleshooting¶
Fixes for the problems you are most likely to hit with Uptime Kuma Monitoring.
The dashboard does not load through port forwarding¶
Cause: the port-forwarding session is not running, the services are not up yet, or something else on your workstation uses port 8443.
Fix: check the services on the instance:
systemctl is-active uptime-kuma.service nginx
curl --cacert /etc/uptime-kuma/tls/cert.pem https://127.0.0.1:8443/dashboard -o /dev/null -w '%{http_code}\n'
A 200 means the instance side works. Restart the port-forwarding session,
and if local port 8443 is busy, use another localPortNumber and open that
port in your browser.
The browser shows a certificate warning¶
Cause: the certificate is self-signed for this instance.
Fix: compare the fingerprint in your browser with
openssl x509 -in /etc/uptime-kuma/tls/cert.pem -noout -sha256 -fingerprint
on the instance. If they match, you are talking to your instance.
You cannot sign in as admin¶
Cause: the admin account was not created, or the password was changed in the dashboard after first boot.
Fix: check the admin unit:
If it failed, run it again:
If you changed the password in the dashboard, the file
/etc/uptime-kuma/admin.password still holds the original one.
First boot failed¶
Cause: sushi-uptime-kuma-firstboot.service failed before the
certificate was created, so the other services did not start.
Fix: look at its log, then run it again and start the services:
sudo journalctl -u sushi-uptime-kuma-firstboot.service --no-pager
sudo systemctl restart sushi-uptime-kuma-firstboot.service
sudo systemctl start uptime-kuma.service nginx sushi-uptime-kuma-admin.service
If it still fails, email info@softwaresushi.com with the instance ID and the log output.
A browser monitor type does not work¶
Cause: Chromium is not installed in this image.
Fix: use an HTTP, TCP, DNS or ping monitor instead.