Check Your IP After You Reconnect
TL;DR: After a router reboot, a Wi-Fi drop, or a switch from cellular to broadband, your public IP may change or it may not. Guessing from yesterday’s screenshot is how tickets go stale. Reconnect, reload a lookup, and read the new provider line before you retry the thing that failed. Refresh your address on Ipsaya once the new link is actually up, not while the laptop still says “connecting.”
The outage that ended with the old address
A design studio lost power for an hour. When the lights returned, the router booted, and the design lead tried the shared drive before the WAN light had stopped blinking. The failure was real. She then tried again five minutes later, still failed, and opened a ticket quoting the public IP from a status mail she had sent the ISP in March. The ISP’s automation looked up March’s address, saw it attached to a different customer who had inherited it in a renumber, and attached her ticket to the wrong modem. A colleague who reloaded a lookup found they were on a new address entirely, because the reboot had drawn a fresh lease. The ticket had to be rewritten. The drive failure, it turned out, was a password prompt caused by the server coming up late, not a routing problem at all.
What a reconnect is allowed to change
Some ISPs hand you the same address for months. Others treat every modem boot as a chance to reassign. Mobile networks change as you move between towers. A laptop that sleeps on Wi-Fi and wakes on a phone tether changes providers in one motion. None of these are misbehavior by the lookup page. The page reports the exit that exists for this request. If you load it before the new link has a route, you get an error, a captive portal, or a stale browser tab that never sent a new request.
- Reload the tab. A page left open from before the outage will keep showing the old number until it fetches again.
- Wait for a real route. Captive portals and “connected, no internet” still count as unfinished.
- Check the provider name, not only the last octet. A new ISP or a VPN fallback is the finding.
- Test the failing device, not the phone that already recovered.
Order of operations after the blink
Give the router two quiet minutes after the WAN light settles. Connect one device. Load the lookup. If it fails, you are not online yet, and no later test of email will be fair. If it loads, note the address and provider. Then retry the original task. If the task fails, the note you hand to support is this address and this timestamp, not the March email. If the task works, you did not need a ticket, and the old address can stay in the past.
Switching from a broken Wi-Fi to a hotspot is a reconnect even when you do not think of it as one. Do it on purpose, confirm the lookup shows the carrier, and remember that some office systems refuse carrier ranges. You may have fixed the outage and tripped a policy in the same gesture.
VPN apps after sleep
A laptop that wakes often restores Wi-Fi first and the VPN second, or the VPN first and badly. Reload the lookup after the VPN icon finishes its animation, not during it. If you needed the ISP address for a local printer’s remote-access check, the VPN address will send you down the wrong path. If you needed the VPN, the ISP address means the tunnel has not grabbed this browser yet. Either way the reload is the measurement. The icon is a claim.
Leases, modems, and the urge to reboot again
Rebooting a second time because the first reboot “did not stick” can draw yet another address and invalidate the note you just sent. Reboot with a reason: a stuck modem light, a firmware apply, a move to a new cable. Then stop and measure. If the lookup address is stable and the problem remains, the problem is above the modem: a password, a DNS name, a remote outage. Another power cycle will not teach you which.
Write the new address into the ticket if you already opened one with the old address. Say that the lease changed. Agents can reconcile two numbers. They cannot reconcile a number you never updated.
If the design lead had put the new lookup address in the first reply, the ISP’s automation would have attached the ticket to the modem that had just booted. The March address was a forwarding error made of confidence. A reconnect is a new measurement. Treat the minute after the WAN light settles as the start of the evidence, and leave older screenshots in the folder where they cannot be pasted by muscle memory.
Measure the link you have now
The studio’s March address was a photograph of a different lease. After the next power cut, wait until the network is willing to load a page, reload the lookup, and use that string for the next ten minutes of debugging. Yesterday’s screenshot can sit in the folder. It should not sit in the ticket.
