From a simple availability check to smart monitoring of Home Assistant, your network, DNS, and internet connection

Home Assistant is excellent at showing what happens inside your smart home. But what if Home Assistant itself becomes unavailable? Or the internet works while DNS does not? Is Home Assistant offline, or is only the external Cloudflare route broken?

That is where Uptime Kuma helps. It is a free, open-source, self-hosted monitoring platform for websites, IP addresses, network services, DNS servers, and other services. Together with Home Assistant, it provides a compact but powerful monitoring setup.

This guide builds a practical configuration with five monitors:

  1. Home Assistant locally
  2. Home Assistant externally
  3. DNS or AdGuard Home
  4. Router
  5. Internet connection

With these five measurements, you can quickly identify which part of the chain causes an outage.

Why use Uptime Kuma alongside Home Assistant?

Home Assistant has system and network sensors, but those are not the same as independent availability monitoring. If the Home Assistant dashboard no longer opens, possible causes include:

Home Assistant has stopped
The host or NUC is unavailable
The router has a problem
DNS is not working
The internet connection is down
Cloudflare Tunnel is unavailable
The TLS certificate causes an error

With Uptime Kuma, you can compare multiple checkpoints. For example:

Router                  ONLINE
Internet                ONLINE
Home Assistant local    ONLINE
Home Assistant external OFFLINE

Home Assistant and the local network still work, so the problem is probably in the external route: Cloudflare, DNS, a reverse proxy, firewall, or tunnel.

Tip: the main benefit is not merely seeing that something is broken. Multiple checkpoints help you determine where it is broken.

What can Uptime Kuma monitor?

Uptime Kuma supports HTTP and HTTPS, Ping, TCP, DNS, port checks, web services, certificate expiry, and many notification methods.

Monitor Method What does it check?
Home Assistant local HTTPS Does Home Assistant respond on the LAN?
Home Assistant external HTTPS Is Home Assistant reachable over the internet?
Router Ping Is the gateway reachable?
Internet Ping Is basic internet connectivity available?
AdGuard Home DNS Does DNS resolution return the expected result?
Zigbee2MQTT HTTP or TCP Is Zigbee2MQTT running?
MQTT TCP Is the broker accepting connections?
NAS Ping or HTTP Is the NAS available?
Public website HTTPS Does the website respond correctly?

More monitors are not automatically better. Start with infrastructure on which other services depend.

Install Uptime Kuma in Home Assistant

Uptime Kuma is available as a Home Assistant Community App. Open:

Settings
→ Apps / Add-ons
→ App Store

Search for Uptime Kuma, install the app, and start it. Check the logs briefly and then open the Web UI.

Depending on your Home Assistant version, the interface may still use *Add-on* where newer documentation uses *App*.

Initial configuration

At first launch, Uptime Kuma asks which database to use. For a normal Home Assistant installation, choose:

SQLite

SQLite is local, simple, and sufficient for a typical home installation. MariaDB is possible, but normally unnecessary. If you use it, create a separate database and user for Uptime Kuma; do not reuse the Home Assistant recorder database.

Create an administrator account with a unique, strong password.

General settings

Under Settings → General, check at least:

  • timezone: Europe/Amsterdam for the Netherlands;
  • server time and displayed timezone;
  • discourage search engine indexing when the service is internal;
  • leave the Base URL empty when you only use Home Assistant Ingress.

A fixed Base URL is mainly useful when Uptime Kuma is exposed directly through its own domain.

Monitoring strategy

The goal is not a random collection of green indicators. Monitor separate layers deliberately:

                INTERNET
                   │
           Internet - IPv4
                   │
                ROUTER
                   │
              Local LAN
                   │
         ┌─────────┴─────────┐
         │                   │
        DNS          Home Assistant
         │                 local
         │
     external route
         │
 Home Assistant external

The combination of monitor states is what makes diagnosis useful.

Monitor 1: Home Assistant locally

This monitor answers one question: can Uptime Kuma reach Home Assistant directly on the local network?

Monitor type: HTTP(s)
Name: Home Assistant - local
URL: https://192.168.1.100
Interval: 60 seconds
Retries: 2
Timeout: 10 seconds

Replace the example address with the IP address of your own Home Assistant server. Two attempts prevent a single brief interruption from immediately becoming an outage.

Local HTTPS and certificates

If a certificate is valid for *.example.com but the monitor requests https://192.168.1.100, the hostname does not match the certificate. Uptime Kuma will correctly report a TLS error.

The clean solution is split DNS:

ha.example.com → 192.168.1.100

Then monitor https://ha.example.com. The certificate remains valid and local traffic does not need to travel through the internet.

For a simple local availability check, you can monitor the IP address and deliberately enable Ignore TLS/SSL error under advanced settings. This confirms that Home Assistant responds over HTTPS, but it no longer validates the certificate hostname. Use this only for the local monitor.

Recommended settings:

Monitor type: HTTP(s)
Name: Home Assistant - local
URL: https://192.168.1.100
Interval: 60
Retries: 2
Timeout: 10
Resend notification: 0
HTTP method: GET
Authentication: None
Proxy: None
Accepted status codes: 200-299
Ignore TLS error: only when directly using an IP address

Useful labels are Home Assistant, Local, and Critical.

Monitor 2: Home Assistant externally

The second monitor deliberately uses the public URL, for example:

https://ha.example.com

With Cloudflare Tunnel, this tests the complete external chain:

Uptime Kuma
    ↓
Public DNS
    ↓
Cloudflare
    ↓
Cloudflare Tunnel
    ↓
Home Assistant

Use:

Monitor type: HTTP(s)
Name: Home Assistant - external
URL: https://ha.example.com
Interval: 60
Retries: 2
Timeout: 10
Method: GET
Accepted status codes: 200-299
Ignore TLS/SSL errors: OFF
Certificate expiry notification: ON, when available

An invalid external certificate should be treated as a real problem. Suggested labels are Home Assistant, External, Critical, and Cloudflare.

Why monitor both local and external access?

If both are online, the application and external route work. If local is online but external is offline, investigate internet, DNS, Cloudflare, the reverse proxy, tunnel, firewall, and TLS. If both are offline, Home Assistant or its host is probably unavailable.

Monitor 3: DNS or AdGuard Home

If you use AdGuard Home, Pi-hole, or another local DNS server, test whether it returns the expected answer instead of only checking whether port 53 is open.

Monitor type: DNS
Name: AdGuard DNS
Hostname: ha.example.com
Resolver: 192.168.1.100
Port: 53
Record type: A
Expected result: 192.168.1.100

This is particularly useful for split DNS, local rewrites, and internal hostnames. It helps distinguish between a stopped DNS service, incorrect data, a broken local rewrite, an unavailable upstream resolver, and an incorrect split-DNS configuration.

Monitor 4: router

Monitor the router or gateway by IP address:

Monitor type: Ping
Name: Router
Hostname: 192.168.1.1
Interval: 60
Retries: 2
Timeout: 5

Useful labels are Network, Router, Local, and Critical.

Monitor 5: internet over IPv4

To test the connection without depending on DNS, ping a stable IP address such as 1.1.1.1:

Monitor type: Ping
Name: Internet - IPv4
Hostname: 1.1.1.1
Interval: 60
Retries: 2
Timeout: 5

Do not use a hostname such as google.com for this specific measurement, because that tests internet connectivity and DNS at the same time.

Interpret outages

The five monitors already form a practical diagnosis matrix.

Internet outage

Router                  ONLINE
Internet - IPv4         OFFLINE
DNS                     possibly OFFLINE
Home Assistant local    ONLINE
Home Assistant external OFFLINE

This usually points to a WAN or provider problem.

Home Assistant problem

Router                  ONLINE
Internet - IPv4         ONLINE
DNS                     ONLINE
Home Assistant local    OFFLINE
Home Assistant external OFFLINE

Investigate Home Assistant or its host.

External access problem

Router                  ONLINE
Internet - IPv4         ONLINE
DNS                     ONLINE
Home Assistant local    ONLINE
Home Assistant external OFFLINE

Investigate Cloudflare Tunnel, the reverse proxy, firewall, public DNS, and TLS.

DNS problem

Router                  ONLINE
Internet - IPv4         ONLINE
DNS                     OFFLINE
Home Assistant local    ONLINE

The local network and internet work, but the DNS infrastructure needs attention.

Connect Uptime Kuma to Home Assistant

Home Assistant has an official Uptime Kuma integration. Open:

Settings
→ Devices & services
→ Add integration
→ Uptime Kuma

If required, first create an API key in Uptime Kuma under Settings → API Keys. Give it a clear name such as Home Assistant, copy it once, and store it safely.

Warning: treat an API key like a password. Never publish it in an article, screenshot, repository, or configuration example.

Depending on the monitor type, Home Assistant can expose status, response time, average response time, uptime over 1, 30, or 365 days, certificate expiry, monitor type, monitored URL, hostname, and port. You can use these values in dashboards, automations, scripts, templates, and notifications.

Example Home Assistant automation

alias: Uptime Kuma - internet outage
triggers:
  - trigger: state
    entity_id: sensor.internet_ipv4_status
    to: "down"

actions:
  - action: notify.mobile_app_your_phone
    data:
      title: "Network outage"
      message: "Uptime Kuma reports that the internet connection is unavailable."

The exact entity ID differs per installation. Verify it under Developer Tools → States.

Create a status page

In Uptime Kuma, open Status Pages → New Status Page. For example:

Name: Home Assistant & Network
Slug: home

The page then uses a path such as /status/home. Create separate groups:

Home Assistant
├── Home Assistant - local
└── Home Assistant - external

Network
├── Router
├── Internet - IPv4
└── AdGuard DNS

Do not expose internal IP addresses, local hostnames, management interfaces, network structure, or security equipment on a public status page. A private status page can contain more detail. A public page should show only public services such as a website, external Home Assistant access, and public APIs.

Notifications

Uptime Kuma can send notifications itself. The advantage is that it can still alert you when Home Assistant is down. Home Assistant can also send notifications and combine additional context, for example:

internet offline
+ router online
+ Home Assistant local online
→ likely WAN or provider problem

Avoid duplicate alerts. Decide which component owns each type of notification.

Maintenance windows

Use maintenance windows for planned Home Assistant updates, router firmware updates, network or NAS maintenance, and planned electrical work. This prevents expected downtime from generating unnecessary alerts and distorting uptime statistics.

Labels and intervals

Useful labels include Home Assistant, Network, DNS, Internet, Local, External, Critical, and Cloudflare. A monitor can have several labels.

For most home networks, start with a 60-second interval and two attempts. Less critical devices can use 120 or 300 seconds. Checking every five seconds normally creates much more traffic and database history without adding useful information.

Advanced extensions

After the base setup is stable, consider monitoring MQTT, Zigbee2MQTT, ESPHome, AppDaemon, a NAS, hypervisor, access points, managed switches, modem, cameras or NVR, solar inverter, EV charger, websites, and API endpoints.

Choose a monitor that tests the service rather than only the device:

Router             → Ping
Internet           → Ping
Home Assistant     → HTTPS
DNS server         → DNS
MQTT               → TCP
Website            → HTTPS

Ping only proves that a device responds to ICMP. It does not prove that an application is healthy. A TCP connection to port 1883 is more useful for an MQTT broker, and an HTTPS request is more useful for Home Assistant.

HTTP status codes, redirects, and TLS

For an HTTP monitor, 200-299 is normally the appropriate success range. Do not hide a server error by adding its status code to the accepted list.

Following a normal redirect from HTTP to HTTPS or to a login page is fine. If many redirects are required, inspect the web configuration instead of increasing the limit indefinitely.

For external HTTPS services, keep TLS validation enabled and enable certificate-expiry checks. Ignore hostname verification only for a deliberate local IP-address test.

Monitor local and upstream DNS separately

One DNS monitor can verify a local rewrite:

ha.example.com → 192.168.1.100

A second monitor can ask the same local DNS server to resolve a public hostname such as one.one.one.one. This distinguishes a working local rewrite from a failed upstream resolver or internet connection.

Backups

When Uptime Kuma runs as a Home Assistant App, its settings and data are included in a Home Assistant backup. Confirm that backups are actually created, stored outside the same machine, and restorable. A backup on the same SSD does not protect against SSD failure.

Prometheus and Grafana

Larger homelabs can include Uptime Kuma in a Prometheus and Grafana monitoring stack. This is usually unnecessary for a normal Home Assistant installation, but can be useful in a larger environment.

Common mistakes

Monitoring only external Home Assistant access

If the only monitor is Home Assistant - external, a red status does not tell you whether the cause is Home Assistant, internet, DNS, Cloudflare, the router, tunnel, or TLS. Multiple strategic checkpoints provide the diagnosis.

Monitoring everything with Ping

Ping is useful but limited. Use HTTPS for applications, DNS for resolvers, and TCP for services such as MQTT.

Mixing internal and external routes

If the internal monitor uses the public hostname, it may still traverse public infrastructure. Check resolution:

nslookup ha.example.com
nslookup ha.example.com 192.168.1.100

A local result might be:

Name:    ha.example.com
Address: 192.168.1.100

If you receive public addresses, you may not be testing the local route you intended.

Start with:

1. Home Assistant - local
2. Home Assistant - external
3. DNS
4. Router
5. Internet - IPv4

For critical monitors, use an interval of about 60 seconds, two attempts, a timeout of 5 to 10 seconds, and no repeated reminders by default. Use GET and status codes 200-299 for HTTP. Validate certificates externally, use IP addresses for pure connectivity checks, and verify the expected response for DNS where possible.

Conclusion

Uptime Kuma becomes especially useful once Home Assistant is responsible for more than a few lights and sensors. Its real value is the ability to test separate parts of the infrastructure independently.

With local and external Home Assistant, DNS, router, and internet monitors, you can often identify the failing network layer in seconds. The configuration remains approachable for beginners and can later grow into TCP monitoring, additional DNS tests, MQTT, status pages, maintenance windows, notifications, Prometheus, and Grafana.

Start small. Make every monitor answer one clear question, and expand only after the foundation is stable.

Sources