When a phone, printer, NAS, or smart-home device disappears from a router list, the DHCP lease record is often the first timestamp you find. It's useful, but easy to read too much into. A lease expiry tells you about an address assignment. Whether a device is offline is a question of current reachability. The two observations are related, but they don't tell you the same thing.
Lease time belongs in a short troubleshooting record alongside other checks. The point is to work out what to check next without changing router settings, assigning a static address, or taking one old entry as proof that a device has failed.
If you first need to find out which addresses and clients are on the local network, start with How to See Every Device on Your Network and Find Its IP Address. The router table, an address scan, and a DHCP record each show a different part of what's happening.
Lease fields and address assignments
DHCP gives a client an address for a limited period. Router interfaces commonly show a client name, MAC address, IP address, start time, expiry time, and sometimes a remaining duration. Labels vary by router. Some routers also keep an old row after the client has left.
The expiry time answers one specific question: how long does the router consider this address assignment valid without a renewal? It doesn't tell you when the device last sent useful application traffic. Nor does it prove that the device is powered on, associated with Wi-Fi, able to reach the router, or reachable from another machine.
A device can have plenty of time left on its lease after you've unplugged it. An old lease can expire while the device remains reachable under a different, valid address assignment, for example after reconnecting with a changed client identifier or private Wi-Fi MAC address. A row that has just expired may also stay visible simply because the router hasn't updated the display yet.
Before reading anything into a date, write down the router time and timezone shown in the interface. An incorrect router clock can make a normal renewal look late. So can a daylight-saving change, or an interface that shows local time while the logs use UTC. On the first pass, record the value as displayed instead of converting it in your head.
The identity behind a client record
Names aren't reliable identifiers. Two devices can advertise the same hostname, and a device may change its name after an update. The router might use a label based on the vendor instead. Compare at least the IP address, MAC address, and any client identifier the router shows against the device itself or a known inventory.
For a Wi-Fi client, check whether private addressing is enabled for that particular network. A phone can use a different MAC address after a network setting changes, a profile is recreated, or the operating system rotates an address. The old lease row may then refer to the same physical device under a network identity it no longer uses. Don't turn that old address into a DHCP reservation until you've confirmed the match.
For a wired client, check the physical path too: cable, switch port, and link indicator. A valid lease tells you little about a disconnected cable. If you're checking a NAS or another server, note separately which service seems to be unavailable. A web interface or file share can fail at a different point from the device's network presence.
A comparison of timestamps
Make a short table or note with four times: the router's current time, the lease expiry or remaining duration, the most recent router client activity if available, and the time of an independent check. That check could be a DHCP renewal log, an ARP/neighbor-table observation from a machine on the same subnet, or a scan from the local network.
Run the independent check once. Note the time and result. A scan can miss a sleeping client, a client behind an isolation rule, or a device on another routed subnet. An ARP entry may be old too. These checks help narrow down the question, but one result won't identify an owner or tell you whether a device is healthy.
Suppose the router shows an address with four hours left on its lease, but a same-subnet scan gets no response and the switch link is down. The lease fits a former assignment; it doesn't contradict a physical disconnection. Or suppose the NAS renews its lease while a NAS web page fails. That points toward the service, name resolution, firewall, or application path rather than the address assignment alone.
Don't keep refreshing the router page without taking notes. Some interfaces update their client table only on a schedule, and a moving countdown makes changes harder to compare. A dated observation before and after a deliberate, harmless check is more useful than several impressions you have to remember.
A low-risk troubleshooting order
Keep the first pass reversible. Save the evidence already on screen, then check one boundary at a time.
- Record the router clock, IP address, MAC address, client name, lease duration, and displayed status.
- If you can access the device, confirm which network it's meant to use and whether its Wi-Fi or Ethernet link is active.
- Check one independent local view, such as the router event log, a neighbor table, or a network scan from the relevant subnet.
- If the address changed, compare the old and new client identifiers before removing the old row or creating a reservation.
- Test the named service separately from network reachability, using its expected local address and port only when you administer that service.
Don't release and renew a lease just to clear a stale row. You may interrupt a working device, and you'll replace an observation with a new event. A router reboot also clears useful context and causes a broader outage. Save or copy the relevant timestamps first.
If a reservation looks like the likely solution, confirm that it uses the identity the client actually presents on this network. A reservation keeps addressing stable. It won't fix Wi-Fi coverage, a sleeping operating system, a failing switch, or an unavailable service. Keeping those possible causes separate makes it easier to verify the result.
Common lease patterns and their limits
An expired row next to a newly assigned address can mean the device simply rejoined the network. Compare identifiers and the order of events before calling it a duplicate device. A still-valid row with no independent response can fit a device that left after receiving its lease, but it doesn't tell you when the device left.
Frequent renewals or repeated new leases may need a closer look. Start with ordinary causes: a short configured lease duration, intermittent Wi-Fi, a device reboot, a private address change, or a router configuration change. Router logs can tell a renewal from a fresh request, provided you can trust their clock.
If a device appears in the router table but not in a scan, check subnet boundaries and client isolation before treating the scan as a complete inventory. A device that answers a scan but has no current lease entry in this router’s display may use a static address, obtain its lease from another DHCP server, or have a valid lease that the display has not yet reflected. When the sources disagree, compare them before drawing a conclusion.
DeviceShelf can provide one local view for recording responding devices and their observed addresses over time. Compare it with router records and the device's own settings. An observed address or name doesn't prove current ownership, identity, or availability.
A conclusion for the next check
When you're done checking, keep the conclusion within what the evidence supports. For example: “At 14:10 local router time, the router retained a lease for 192.168.1.42 until 18:00; the device did not answer one local scan, and the Ethernet link was down.” That's stronger and more useful than “the device went offline at 14:10.”
Choose one observable next action, whether that's inspecting a cable, reconnecting to the intended Wi-Fi network, checking a service log, or waiting for the next renewal. Afterward, check the same identifiers and timestamps again. A short record helps keep an old lease from becoming a lasting explanation for a problem it never proved.