Store Networks
Part of Retail store networks
Monitoring internet outages at several stores
Use store, link and task signals to investigate internet outages, route alerts and record incidents across locations.
Monitor each store from more than one point in its connection path. Make alerts state which trading task is affected. A gateway shown as offline identifies a place to investigate; by itself it does not prove the internet provider is at fault or show whether checkout can continue.
Use distinct signals
Record a consistent store identifier, primary and backup links, gateway and support owner. Choose checks that answer different questions.
| Signal | What it can show | What it cannot establish alone |
|---|---|---|
| Gateway and uplink status | The state reported by local equipment | Whether a payment or staff application works |
| Probe sent from the store | Whether its destination responds under the probe's rules | Whether every destination is reachable |
| Probe sent towards an approved store endpoint | Whether that endpoint responds from outside | Whether an internal task works |
| Staff report or authorised task check | The effect on a workflow | The technical cause |
An external check needs an approved endpoint and may be unavailable for some stores. If local power or the gateway fails, telemetry may stop too; use other observations and staff reports.
Signal Types and Their Diagnostic Value
- Gateway and uplink status
- State reported by local equipment (e.g. Meraki MX/Z-Series)
- Probe sent from the store
- Destination response under probe rules
- Probe sent towards approved endpoint
- External reachability of an approved store endpoint
- Staff report or authorised task check
- Workflow impact (e.g. checkout failure)
Route alerts to an owner
An alert should identify the store, symptom, first detection time, affected link or task, and whether a backup route is reported active. Send it to someone able to contact the provider or guide staff. Include an escalation route when that person is unavailable, and group repeated notices from the same event.
Do not label every failed probe an internet outage; the destination may reject the check while other services work. Cisco Meraki documents that the Uplink tab lets administrators monitor uplink status for MX and Z-Series appliances.
Keep a useful incident timeline
Record detection, staff confirmation, trading effect, provider contact, backup activation, link restoration and final task check as separate events. A restored link does not establish that queued work was processed or an interrupted payment was resolved. Verify the affected task before closing the incident.
Use consistent definitions across stores. Count confirmed incidents separately from brief probe failures and planned work. Review recurring faults, late alerts and cases where evidence did not identify an owner.
Network-device security and configuration logs can help investigate a local change. They are not a substitute for service checks.
Rehearse the response
Use a platform simulation or a controlled test path approved by the store's support and trading teams. Check that the correct store and link appear, the intended person receives the alert, staff get usable instructions and recovery is recorded. Schedule any disruptive test with the store.
Steps to Respond to an Internet Outage
- Use a platform simulation or controlled test pathApproved by store support and trading teams
- Verify correct store and link are identifiedEnsure accurate alert routing
- Confirm intended recipient receives alertInclude escalation path if unavailable
- Provide staff with usable recovery instructionsClear, role-specific guidance
- Record recovery actions in systemFor audit and review purposes
