failure
A Customer Is Offline. What Do You Check Before You Tell Them Anything?
Check whether this customer is the only one affected, whether their equipment is reachable and actually documented, and whether a recent change lines up with the outage; then give them a status, a next check time, and no speculation. SignalNook keeps the asset map, health signals, and incident record in one desk so that call goes faster. You can open these pages and sign in to the workspace today. That does not mean SignalNook is connected to your routers or monitoring systems, and it does not mean the product has formally launched.
What makes small-ISP outages hard
Fixing the link is rarely the hard part. The hard part is knowing which customer, which asset, and what changed, before anyone promises anything. Operators who answer that in order give honest statuses quickly; operators who skip it either promise too much or go quiet, and both cost subscribers.
Read-only monitoring cannot diagnose assets that are unreachable or undocumented. If the device serving this customer was never mapped, locating it is step one, and the status you give the customer should say plainly what you do not yet know.
What to have at hand
The customer's site or account, the assets that serve them as documented on your map, the change log for those assets, and your standard wording for the two states customers can tell apart: being investigated, and identified with a next step.
Step 1: Confirm the scope before touching anything else
One customer, one site, one neighborhood, or the uplink? Scope changes everything downstream: a single-customer fault is a service call, a shared-segment fault is an incident, and an uplink fault is an all-hands message to every affected subscriber within the hour.
Step 2: Open an incident record tied to the customer and site
Start the record before diagnosing, not after. It should name the customer, the site, the time reported, and the assets suspected. An incident that starts life undocumented gets reconstructed from memory later, which is how resolution logs turn into fiction.
Step 3: Compare the outage against recent changes
Line up what changed on those assets in the last few days against when the symptoms started. A change that coincides is a lead worth checking first, but treat correlation as a lead, never as a confirmed cause in front of the customer.
Step 4: Give the customer a status and a next check time
Three things: what you know (outage confirmed, scope), what happens next, and when they will hear from you even if nothing new turns up. No cause talk until cause is confirmed, no fix times you cannot support. Customers forgive outages; they do not forgive silence or guesses presented as facts.
Step 5: Close the loop in the resolution log
When service returns, record what was actually done, what the confirmed cause was if found, and what remains unknown. The log entry should match reality, including the embarrassing parts, because next winter's you will be reading it at speed.
Verification
The incident record names the customer, the affected assets, and either the matching change or the finding that nothing changed. The customer received a status and a next check time, and the resolution entry describes what was done rather than what was hoped. If the record says undocumented anywhere, that word made it into the customer status too.
Limits during the outage
Read-only monitoring cannot diagnose assets that are unreachable or undocumented. Network, billing, and DNS mutations require operator authorization. SignalNook assembles the record while you act on the network.
Do not present a correlation with a recent change as a confirmed cause, and do not promise restoration times the evidence does not support.
Where SignalNook sits during an outage
SignalNook holds the asset map, collects read-only health signals, opens the incident record pointed at the affected customer and site, and lines up recent changes beside the timeline. Ask it to show every asset at the site and everything that touched them lately.
You run the checks, you decide any change to the network, and you make the promises.
FAQ
Questions this guide is for
Does SignalNook have a public API or MCP integration?
No. SignalNook has no public API or MCP integration. Asset mapping and read-only health collection run in the workspace, assembling an incident record that points to the affected customer or site.
Can SignalNook restart my router or change DNS records?
No. Network, billing, and DNS mutations require operator authorization, and read-only monitoring cannot diagnose assets that are unreachable or undocumented.
Does SignalNook reboot the router for me?
No. Network, billing, and DNS mutations require operator authorization. The desk assembles the record; your hands touch the network.
The device was never added to the map. Now what?
The record says undocumented, and the honest customer status says you are still locating the equipment. Read-only monitoring cannot diagnose what it cannot see, and pretending otherwise just moves the embarrassment later.
How detailed should the customer message be?
Status, scope, and next check time. Cause enters the message only after confirmation, not while it is still a suspect.
Start in the workspace
Open the incident record properly
Sign in or create an account. You return to the SignalNook conversation. Name the customer and site, pull up their assets and recent changes, and send the first status inside the hour.