The PSTN Goes Dark in 100 Days: Audit the Legacy Dependencies Your Monitoring Forgot

Openreach has confirmed there will be no more extensions: the UK's public switched telephone network is switched off on January 31, 2027. Roughly 100 days from now, every analog copper line still in service goes dead. If you run infrastructure for an internal IT team, or you are an MSP technician responsible for 30–60 client environments, that date should trigger two uncomfortable questions: what is still plugged into those lines, and what in your alerting chain quietly assumes they exist.

This is not a telephony project to hand off to the voice vendor. It is an infrastructure monitoring problem, and it exposes the same weakness that causes most outages to be discovered by users instead of IT: the parts of the estate nobody watches are the parts that fail loudest, at the worst time, with nobody accountable.

Why This Is a Monitoring Problem, Not a Phone Problem

Analog lines have never been monitored. There is no SNMP on a fire alarm panel, no agent on a lift emergency phone, no health check on the fax line your finance team still needs for supplier remittances. When one of those lines fails — or gets killed in the switch-off — the first signal arrives as an angry call from a facilities manager, a failed lift inspection, or a payment terminal that will not dial out. By then you are not responding to an incident; you are explaining one.

Digital voice makes it worse by collapsing the blast radius. Once a line is migrated, the phone line is the router. A cheap edge device that reboots itself during a firmware update now takes down lift comms, door entry, and the telecare dialer with it. Most monitoring setups treat the edge router as ordinary network gear, not as the thing your phone lines depend on, so nothing pages anyone when it flaps.

And the part almost nobody has audited: your own alerting. Dial-up out-of-band modems bolted onto UPS units, SMS gateways riding on cellular dialers, paging systems that place an actual phone call — these paths were built on the assumption that copper exists. When the PSTN dies, your backup alert path dies with it, and you only find out on the night the primary path fails too. That is how a 02:00 disk-full alert becomes an 08:40 user ticket and a very bad morning.

What Your Current Tooling Gets Wrong

Most teams are running tool sprawl that makes this impossible to see coming. Your RMM (NinjaOne, ConnectWise, Datto) watches endpoints. A separate uptime tool (PRTG, Uptime Kuma) pings servers. The telephony portal belongs to the voice vendor. The helpdesk (Freshservice, HaloPSA, ConnectWise Manage) sits disconnected from all three. When the edge router drops and every phone in the office goes dark, each system reports a different fragment of the same incident, nothing correlates, and the SLA clock burns while two vendors point at each other.

The gaps exist because these tools were built in silos. The monitoring configuration was written years ago, when the POTS line was a reliable constant nobody needed to watch. The network team owns routers, the voice vendor owns lines, the sysadmin owns servers — and no tool shows the dependency between them. There is no topology view that says this digital voice adapter, this door controller, and this EPOS terminal all hang off the same switch, so if that switch dies, here is everything that breaks.

For MSPs, multiply the problem by client count. Forty clients, two or three analog lines each — fire panels, alarm dialers, a fax in the warehouse — with migration status tracked in a spreadsheet nobody has updated since last quarter. Meanwhile the helpdesk and monitoring live in separate systems, so when you try to report on response times, the monitoring tool says the outage started at 06:52 and the helpdesk says the first ticket arrived at 08:41. Which timestamp goes into the SLA report? Neither, honestly. You are assembling fiction from two half-truths.

How AlertMonitor Closes the Gap

This is exactly the scenario AlertMonitor was built for: one platform where the entire stack — servers, services, applications, Windows workstations, scheduled tasks, and network devices — is monitored in real time with a single alert stream.

Concretely:

• Topology mapping shows what sits behind every edge device. You can see that the digital voice adapter, the door entry controller, and the EPOS terminal all hang off the same switch — so before you approve any router change during the migration, you know the full blast radius.
• Intelligent alerting pages the right person in seconds, with escalation if nobody acknowledges. A router that flaps three times in ten minutes triggers a page — not a quiet log entry someone stumbles across at 09:00.
• Integrated helpdesk means the alert auto-creates a ticket with device, service, and history attached. Your SLA report finally comes from one dataset with one set of timestamps, so it reflects reality.
• RMM and patch management close the loop: the on-call tech opens a remote session, runs the remediation script, and keeps the Windows boxes in the voice path — recording servers, fax-to-email gateways, SBC-adjacent tooling — actually patched, so the fix stays fixed.

The old fragmented way looks like this: router fails → nobody notices → users call → helpdesk ticket → helpdesk pings the network team → network team checks a different tool → 50+ minutes gone. In AlertMonitor it looks like this: router fails → three failed checks in 90 seconds → on-call paged → ticket created automatically → remote session opened → resolved before the office wakes up.

Practical Steps: Run This Audit This Week

1. Inventory every analog dependency. Walk each site. Ask the alarm vendor, the lift maintenance contractor, and facilities. Fire panels, lift lines, telecare devices, door entry, EPOS backup lines, fax. Get each one into your CMDB with an owner and a migration decision.

2. Find the Windows services that hint at copper. Stopped automatic services are where legacy dependencies hide — fax services, modem services, line-test agents. Run this on your servers:

Get-Service |
    Where-Object { $_.StartType -eq 'Automatic' -and $_.Status -ne 'Running' } |
    Select-Object Name, DisplayName, Status |
    Export-Csv -Path "C:\Reports\Stopped-Auto-Services.csv" -NoTypeInformation

Anything stopped that references fax, modem, or telephony is a lead worth chasing before January 31.

3. Find the scheduled jobs that were supposed to tell you. Many estates have a scheduled task that runs a line test or emails a backup report. If it has been failing silently for months, you have been blind and did not know it:

Get-ScheduledTask | Where-Object State -ne 'Disabled' | ForEach-Object {
    $info = Get-ScheduledTaskInfo -TaskName $_.TaskName -TaskPath $_.TaskPath
    if ($info.LastTaskResult -ne 0) {
        [PSCustomObject]@{
            Task     = "$($_.TaskPath)$($_.TaskName)"
            LastRun  = $info.LastRunTime
            ExitCode = $info.LastTaskResult
        }
    }
} | Sort-Object LastRun -Descending |
    Export-Csv -Path "C:\Reports\Failed-Scheduled-Tasks.csv" -NoTypeInformation

4. Test the VoIP path before your users do. If lines have been migrated to digital voice, verify the SIP endpoints can actually reach the provider — SIP ALG on a router or a firewall rule change will break registration silently:

$targets = @("sip.yourprovider.com", "sbc.yourprovider.com")
foreach ($endpoint in $targets) {
    $result = Test-NetConnection -ComputerName $endpoint -Port 5060 -WarningAction SilentlyContinue
    "{0} : TCP 5060 {1}" -f $endpoint, $(if ($result.TcpTestSucceeded) { "OPEN" } else { "BLOCKED" })
}

5. Sweep the edge devices that now carry phone lines. For each client site, know the public IPs of edge routers and digital voice adapters, and check reachability from a bastion host:

#!/bin/bash
# Reachability sweep for edge devices and ATAs per site
devices="203.0.113.10 198.51.100.22 192.0.2.5"
for ip in $devices; do
  if ping -c 3 -W 2 "$ip" >/dev/null 2>&1; then
    echo "$ip OK"
  else
    echo "$ip UNREACHABLE - investigate ATA/edge device now"
  fi
done

6. Turn one-off scripts into permanent monitors. A script you run once tells you about yesterday. In AlertMonitor, these become persistent checks: uptime monitors on every edge device and ATA, service monitors on the voice-path Windows boxes, scheduled task monitors that page when a line-test job fails. The audit script becomes the monitoring policy, with escalation chains behind it.

The Deadline Is a Gift

January 31, 2027 is fixed. The teams that treat it as a forcing function will come out of it with a complete dependency inventory, an alerting chain that does not depend on a network that no longer exists, and a single pane of glass that would have caught the router flap, the stopped fax service, and the failed line-test task months earlier. The teams that treat it as a phone vendor problem will spend the first week of February explaining dead lift lines to facilities managers.

Run the audit. Fix the alert paths. Put the whole stack under one pane of glass before the copper goes quiet.

Related Resources

AlertMonitor Infrastructure & Server Monitoring AlertMonitor Platform Overview Book a Demo Infrastructure & Server Monitoring Resources