Home Assistant Internet Monitoring: Check Outages Safely

Researched from current Home Assistant, Google and Cloudflare documentation on October 21, 2026. The configuration and examples below are documentation-based; Tara has not tested them on a household network or measured outage-detection times. The cover is an editorial illustration.

Start with reachability, then investigate the service

For useful Home Assistant internet monitoring, start with a small set of independent checks and a warning that says exactly what failed. A ping sends a small network message and waits for a reply. The built-in Ping integration—the connection-checking tool—checks from the computer running Home Assistant, so its view can differ from your phone’s Wi-Fi connection.

Use the router check to investigate the local path, and external checks to observe paths beyond the house. Keep a separate note of what was actually failing: all websites, one streaming service, a cloud-connected light, or only one phone. The procedure below records clues without taking control of the network. You need a working Home Assistant installation, permission to add integrations and automations, and the router’s actual local address.

1. Add three checks while the connection is healthy

1. Find the router or default-gateway address in your network settings. An address such as 192.168.1.1 is only an example; use yours.
2. Open Settings → Devices & services → Add integration and select Ping (ICMP). Enter that address as the host.
3. Repeat for 1.1.1.1 and 8.8.8.8. These are Cloudflare and Google public resolver addresses, used here as ping targets. This does not change your home’s DNS settings.
4. Give the three connectivity sensors clear names: Router reachability, Cloudflare reachability and Google reachability. Copy their entity IDs from their settings. An entity ID is Home Assistant’s exact identifier for a reading.

Keep the default polling interval to begin with: the Ping documentation specifies 30 seconds. Confirm that each target normally answers before relying on it. A router that deliberately ignores ping is a poor baseline; a failed reply alone does not justify changing its security settings.

The connectivity sensors display Connected or Disconnected, stored as on or off. unknown and unavailable mean the reading itself is missing. Do not turn those into “internet down” or “healthy.” The optional round-trip-time and packet-loss sensors can help later, but are not required for this first warning.

2. Put the separate readings on one timeline

Add the three current readings to an existing dashboard you edit manually. Add a built-in History graph card beside them, using its code editor for this configuration. Replace the sample entity IDs with yours. This needs no custom dashboard card or HACS download.

type: history-graph
title: Connection checks from Home Assistant
hours_to_show: 24
entities:
  - entity: binary_sensor.router_reachability
    name: Router
  - entity: binary_sensor.cloudflare_reachability
    name: Cloudflare
  - entity: binary_sensor.google_reachability
    name: Google

The history card displays available recorded history; it cannot reconstruct a time when Home Assistant was off. Treat the following table as a guide to your next check, not proof of the cause.

Swipe horizontally to read all columns.

Worked example: at 19:10, the Google row becomes disconnected while Cloudflare and the router still answer. Keep watching; do not reboot anything. At 19:12 both external rows are disconnected but the router still answers. The warning below becomes eligible after both external readings have each stayed off for two minutes. If another device can still browse, investigate the Home Assistant host’s path. These are hypothetical observations, not a Tara measurement.

3. Create one local warning for sustained failures

Create a new automation in Settings → Automations & scenes. In its menu, choose Edit in YAML and paste the example. Replace both sensor IDs everywhere. Labels can differ between releases; use the corresponding state trigger, state condition and persistent-notification action.

alias: Internet probes - sustained failure
triggers:
  - trigger: state
    entity_id:
      - binary_sensor.cloudflare_reachability
      - binary_sensor.google_reachability
    to: "off"
    for: "00:02:00"
  - trigger: time_pattern
    minutes: "/5"
conditions:
  - condition: state
    entity_id: binary_sensor.cloudflare_reachability
    state: "off"
    for: "00:02:00"
  - condition: state
    entity_id: binary_sensor.google_reachability
    state: "off"
    for: "00:02:00"
actions:
  - action: persistent_notification.create
    data:
      notification_id: internet_probe_warning
      title: External connection checks failed
      message: >-
        At {{ now().strftime('%Y-%m-%d %H:%M:%S') }}, both
        external ping sensors had reported disconnected for
        at least two minutes. Check their current states and
        the router before diagnosing an internet outage.
mode: single

The two state conditions are both required. One failed target, a brief interruption or a missing sensor does not qualify. The five-minute check revisits an ongoing failure after a reload or a missed transition. Trigger waiting periods reset on restart or reload, so this is a fresh check of the current readings, not recovery of an exact outage start time.

A fixed notification ID updates the same warning during continued failure. If dismissed while both probes still fail, it returns at a later five-minute check. While Home Assistant keeps running, the notice remains until dismissed even after connectivity returns: its timestamp records the latest failed check, while the dashboard shows current status. Polling, timeouts and the chosen hold period add delay; this example will miss some short interruptions.

This warning appears inside Home Assistant. It is not a phone push notification. If you later add phone alerts, account for the delivery path: a phone on mobile data cannot receive a message from a home server that has no route out. Companion Local Push can use a working direct connection with platform-specific setup; it does not create a backup internet connection.

4. Rehearse without interrupting the house

Use two Toggle helpers as pretend probe results. They store values inside Home Assistant and do not switch a physical device.

1. Under Settings → Devices & services → Helpers, create two Toggle helpers named Probe test A and Probe test B. Turn both on.
2. Create a separate copy of the warning automation. Replace every sensor ID with the appropriate test helper ID. Set all three two-minute durations to 10 seconds, remove the time-pattern trigger from this copy, and use internet_probe_test as its notification ID.
3. Turn A off and leave B on for more than 10 seconds. Expected: no test warning. Then turn B off and wait more than 10 seconds. Expected: one test warning.
4. Dismiss that test notice. Turn both on, then turn both off for only five seconds before restoring them. Expected: no new notice. Open the automation’s traces to inspect the trigger and conditions.
5. Disable the rehearsal automation. In the real version, confirm the actual Ping IDs, two-minute durations and five-minute recheck before enabling it.

This checks the rule and local notification, not the ISP, real packet loss or phone delivery. Pressing “Run actions” alone bypasses the failure logic, so it is not a substitute for changing the practice helpers. If the real automation behaves unexpectedly, use the trace-first automation checklist.

5. Check DNS separately when pings succeed

DNS translates a name such as www.home-assistant.io into an address. Google’s DNS troubleshooting guide explicitly separates this from ping timing and notes that ICMP traffic can receive lower priority. A good ping is not a completed website request.

For an additional diagnostic reading, add DNS IP through Devices & services. Set a public hostname and explicitly choose the resolver—the service that answers name lookups—you want to examine. To check your household DNS service, use its address if it accepts DNS queries from Home Assistant. A test against a different public resolver would check a different path.

The default DNS IP setup finds your public IP through OpenDNS; do not mistake that for a test of your usual resolver. DNS IP normally checks every two minutes and becomes unavailable after failed retries. That failure can concern the chosen name or resolver, so leave it separate from the two-ping rule. A successful lookup still does not verify HTTPS or a vendor’s cloud service.

Keep the diagnosis narrower than the evidence

The example external addresses test IPv4. They do not establish IPv6 health, discovery of devices, commands reaching those devices, device-initiated updates such as camera events, or a complete Matter path. A virtual machine, Container installation or isolated network can give Home Assistant different access from a laptop. Investigate that path without adding interfaces or opening firewall rules just to make a status light green.

Home Assistant must remain powered and running to observe failures. For a local device that instead reports unavailable, use the separate unavailable-device notification guide. If you want to total the recorded failed-probe time, the History Stats walkthrough explains the calculation and missing-history limits; label it “probe disconnected time,” not certified ISP downtime.

Tara’s recommendation is to keep the first response informational. Automatic modem power cycling can interrupt working calls and devices or hide the original fault. If you are planning the broader system, the local smart-home hub guide explains where the controller fits.

Frequently asked questions

Does a failed ping prove my internet provider is down?

No. It proves that this check did not receive the expected reply. Compare the router, another external target and a real service from another device before assigning a cause.

Why not use an internet speed test as the outage sensor?

A speed test asks how much data can pass during that test. The warning here asks whether two selected targets answer. Keep those questions separate; a slow or failed speed test is not by itself a whole-home outage diagnosis.

Will the warning clear automatically when the connection returns?

No. This example deliberately keeps one timestamped observation until you dismiss it. Read the current probe cards to see what is happening now.