How Long Does the Internet Take to Reroute a Broken Cable?

The Internet can route around a broken cable before a person has time to notice—or fail to route around it at all. The difference is not the size of the cable. It is whether the affected network has a genuinely independent backup path, detects the failure quickly, has enough spare capacity, and is configured to use that path automatically.

Inside a well-engineered backbone, precomputed fast-reroute protection can redirect traffic in tens of milliseconds. A broader routing change may take seconds to several minutes to settle. During a major submarine-cable failure, traffic can move to surviving cables while users still experience congestion, high latency, and intermittent failures for hours or longer. If an excavator cuts the only line serving a house, neighborhood, business, island, or landing station, there may be nowhere to reroute; service waits for another connection or a physical repair.

The most important distinction is between traffic restoration and cable repair. The route can change electronically in moments. Repairing buried terrestrial fiber can take hours or days, while an International Telecommunication Union guideline estimates one to three weeks as the mean repair time for a submarine cable, depending on location, depth, ship availability, cause, and weather.

Quick Answer

When a working alternate route already exists, Internet traffic may begin moving around a broken cable in tens of milliseconds to a few seconds inside a carrier or data-center network. Changes that must propagate between independent networks through the Border Gateway Protocol, or BGP, commonly take tens of seconds to several minutes and can occasionally take longer. Users may see brief packet loss, frozen calls, slow pages, or restarted connections while the network converges.

Use these as planning ranges, not promises:

Failure and protection situation	Typical order of magnitude	What users may notice
Precomputed IP or MPLS fast reroute	Tens of milliseconds after failure detection	Often nothing, or a tiny burst of packet loss
Fast failure detection with an alternate path	Roughly tens of milliseconds to about a second, depending on configuration	A brief glitch, packet loss, or reordered packets
Routing within one provider after a direct link-down signal	Often subsecond to several seconds	Short interruption or latency change
Timer-based internal failure detection	Several seconds to tens of seconds	Noticeable pause or temporary outage
BGP change between Internet networks	Tens of seconds to several minutes; longer cases occur	Some destinations recover earlier than others
Major submarine-cable cut with surviving capacity	Rerouting may begin quickly, but degraded service can persist	Higher latency, congestion, slow downloads, failed sessions
Cut to a single-homed home, business, town, or island	No automatic route around it	Outage continues until backup access or repair is available
Physical repair of a submarine cable	Commonly weeks, not seconds	Traffic may remain on slower or crowded alternate paths

No routing protocol creates a path that does not physically exist. Redundancy must use separate cables, conduits, landing points, providers, routers, or technologies. Two services that share the same underground duct can fail together.

Four Clocks Start When a Cable Breaks

People often combine four separate events into one “rerouting time.” Engineers measure them separately.

1. Failure-detection time

The adjacent equipment must discover that the path no longer works. A clean fiber break can make an optical interface report link down quickly. A one-way failure, damaged amplifier, intermittent signal, remote equipment problem, or failure hidden behind another transport system may require keepalives or a liveness protocol to expire.

Bidirectional Forwarding Detection, or BFD, is designed to detect forwarding-path failures rapidly. RFC 5880 gives a 50-millisecond example using a 16.7-millisecond transmission interval and a multiplier of three. That example demonstrates what an aggressive configuration can do; it is not a default for every network. AWS documents a Direct Connect example in which a 300-millisecond BFD interval multiplied by three produces 0.9-second detection.

2. Local protection time

Once the failure is known, the nearby router or optical system may switch to a backup that was prepared in advance. RFC 4090 describes MPLS fast-reroute mechanisms that redirect traffic to backup label-switched tunnels in tens of milliseconds. RFC 5286 describes precomputed loop-free alternate next hops for IP networks, with the goal of reacting in tens of milliseconds.

This local action protects traffic while the wider network recalculates. It is fast because the router does not have to ask the entire Internet what to do first.

3. Routing-convergence time

Routers must agree on the new best paths. Inside one network, an interior routing protocol can advertise the topology change and recalculate routes. Between separate networks, BGP announcements and withdrawals propagate through many independently operated systems.

Different routers can update at different moments. During convergence, one source may reach a site while another still follows a stale or failing route. The Internet does not flip from one globally consistent map to another at one instant.

4. Capacity-recovery time

Moving packets is not the same as giving them the same performance. A backup link may carry ordinary overflow but lack room for an entire failed cable’s load. Traffic can reroute within seconds and remain slow until operators add capacity, change traffic-engineering policy, obtain emergency transit, or repair the original facility.

These four clocks explain why a monitoring system can show traffic on an alternate route while customers continue reporting an outage.

How Routers “Know” a Cable Is Broken

Routers do not see a backhoe, ship anchor, landslide, or snapped glass fiber. They observe electrical, optical, or protocol symptoms.

A directly connected router may receive a hardware link-down indication. In a simple point-to-point fiber connection, that can be the fastest and cleanest signal. Complications arise when the apparent IP link crosses several optical devices, carrier circuits, switches, tunnels, or shared transport systems. The router-facing interface can remain up even though packets no longer reach the far end.

Networks therefore combine several detection methods:

optical loss-of-signal and physical-interface alarms;
Ethernet operations, administration, and maintenance mechanisms;
routing-protocol hello and dead timers;
BFD control packets;
BGP keepalives and hold timers;
active probes and service-health checks;
packet-loss, latency, and error-rate monitoring; and
reports from downstream networks and customers.

Timer settings involve a tradeoff. Short timers detect faults faster but create more control traffic and can turn a brief congestion event into unnecessary route changes. Longer timers reduce false reactions but allow packets to follow a dead path longer.

OSPF illustrates this balance. RFC 2328 uses a ten-second HelloInterval as a sample local-area-network value and suggests a RouterDeadInterval that is a multiple—such as four times—the hello interval. Those are examples in the standard, not universal modern carrier settings. A direct link-down notification or BFD can trigger much faster than waiting for a silent-neighbor timer.

Why a Damaged Cable Can Be Harder Than a Completely Broken One

A clean break can produce an immediate loss-of-signal alarm. A damaged fiber, failing optical component, loose connector, water intrusion, or intermittent power problem can be more deceptive. The path may continue carrying some traffic while its error rate, delay, or packet loss becomes unacceptable.

Routing protocols primarily answer Can this neighbor or destination still be reached? They do not automatically understand every application-quality problem. If keepalives continue to pass, a route can remain selected while video calls freeze and downloads repeatedly retry. Short health probes may succeed between bursts of loss. A backup path can exist but remain unused because the primary never crosses its failure threshold.

Operators may need to correlate:

optical receive power and error counters;
packet loss and latency from several locations;
interface flaps and routing adjacencies;
application failures;
weather, construction, ship, or power events; and
alarms from equipment along the transport path.

They may then lower the route preference, shut an interface, drain traffic, or remove the faulty circuit manually so automatic routing can choose the alternate. That intervention can make a deteriorating service appear to “reroute” more slowly than a total cut.

Fast detection is not always safe detection. If a network reacts to every short burst of congestion as though a cable were severed, routes can flap between paths and disrupt more traffic. Engineers set thresholds to distinguish a persistent failure from a transient problem, accepting that ambiguous faults may take longer to classify.

For users, this explains an outage that comes and goes. The cable may not be cleanly broken, and the provider may be working to identify which layer is failing before moving all traffic.

What Fast Reroute Actually Does

Ordinary routing computes the preferred next hop toward each destination. Fast reroute adds a safe alternate before anything breaks.

When the primary next hop fails, the local router immediately uses the precomputed alternate. Other routers can then complete their normal topology calculations in the background. This reduces the packet-loss window and avoids waiting for full distributed convergence before forwarding resumes.

Several limitations matter:

A safe alternate may not exist for every destination or topology.
The backup may protect one link failure but not the simultaneous loss of a router, conduit, landing site, or multiple cables.
Two apparently separate links may share a physical risk, called a shared-risk link group.
The alternate can be operational but congested.
Fast reroute within one provider does not force every other Internet network to update equally fast.
Misconfiguration can leave a backup advertised but unusable.

RFC 5286 explicitly notes that coverage depends on topology. The Internet’s reputation for routing around damage is earned through deliberate redundancy and engineering—not a magical property of every IP connection.

Why BGP Takes Longer Than a Local Switch

BGP is the routing protocol that exchanges reachability between autonomous systems: Internet providers, cloud networks, content networks, universities, governments, and other independently administered networks.

When a cable failure removes a usable path, a network may select another route it already knows. It can then send updates or withdrawals to neighbors. Those neighbors apply their policies, choose their own best paths, update forwarding tables, and inform additional neighbors.

The process takes longer than a local backup switch because:

the change crosses many organizations and routers;
each network applies its own import, export, and path-selection policies;
some routers have several alternate paths to test;
update pacing and processing capacity vary;
a BGP session may not fail until its hold timer expires;
route flap damping or other stability controls may delay acceptance; and
a withdrawal can expose another path that later proves unusable, producing additional changes.

RFC 4271 requires a negotiated BGP Hold Time to be zero or at least three seconds. Actual operational timers vary. RFC 8327 notes that BGP Hold Timers are commonly 90 to 180 seconds in the maintenance scenario it discusses and that convergence on a slow router receiving a full Internet routing table could add as much as 15 minutes. That is evidence of possible slow cases, not a claim that every cable cut takes 15 minutes.

A RIPE Labs analysis of BGP update behavior found new route visibility rose rapidly, while route withdrawals took longer and fell below ten percent visibility after approximately two minutes in the studied data. The researchers summarized global BGP convergence as generally taking a few minutes. Results differ by event, prefix, vantage point, and era, so they should not be converted into a guaranteed countdown.

Why Some Connections Break Even When Rerouting Works

Routing restoration saves reachability, but an individual session can still fail.

Packets are lost during detection

Until a router recognizes the fault, it may continue sending packets toward the broken link. Real-time voice, video, gaming, remote desktops, and financial transactions are especially sensitive to a burst of loss.

Packets arrive out of order

Old-path and new-path packets can reach the destination in a different sequence. Transport protocols can recover, but the reordering may briefly reduce performance.

The new route is longer

An alternate may cross another city, country, ocean, or provider. Round-trip delay can increase even though the destination is reachable.

The backup is congested

If several hundred gigabits or terabits move onto links designed for ordinary loads, queues grow and packets drop. A speed test can look like a partial outage.

Stateful equipment sees a new path

Firewalls, carrier-grade NAT, tunnels, and load balancers maintain connection state. A route change that produces asymmetric traffic or moves the flow through different stateful devices can reset a session.

Path characteristics change

The alternate can have a different maximum transmission unit, filtering policy, or quality. Applications may need to reconnect even after basic IP reachability returns.

This is why a video call can freeze while a newly opened webpage works, or why some sites return before others.

Not Every Broken Cable Is a Backbone Cable

The answer changes dramatically depending on where the break occurs.

A cable inside a data center

Well-designed data centers use multiple links, switches, and equal-cost paths. A failed member link may be removed from an active group quickly, with traffic continuing across the remaining members. A poorly designed rack or single-attached server may simply go offline.

A metropolitan or long-haul provider fiber

Carrier networks often use rings, diverse routes, MPLS protection, and internal fast-reroute mechanisms. Recovery can be fast if the alternate avoids the same damaged duct and has capacity.

An interconnection or peering cable

Traffic may shift to another port, facility, peer, or transit provider. BGP policy and available capacity determine how smoothly this happens.

A submarine cable

International traffic may move to another undersea system, cross-border terrestrial fiber, or, for a small portion of demand, satellite. The detour can be far longer and more congested. Countries with multiple cable landings and terrestrial connections are more resilient than places dependent on one system or one coastal corridor.

A neighborhood feeder or last-mile drop

The cable between an ISP node and a home usually has no packet-level alternate. A cable modem, fiber terminal, or router cannot route through a physical path that the provider never built. The customer needs a separately delivered backup—such as cellular, fixed wireless, satellite, or another provider—or must wait for repair.

The familiar instruction to reboot a router can restore a stuck device, but it cannot heal cut fiber or create a second line.

What Happens When a Submarine Cable Breaks?

Submarine networks demonstrate the difference between rerouting and repair on a large scale.

Operators first identify the affected span and shift traffic where contracts, capacity, and routing permit. Networks with several geographically diverse cables can remain online. Networks dependent on the failed corridor can lose most international access. Local services connected through an Internet exchange point or local cache may keep working even when distant services do not.

The Internet Society’s report on the May 2024 East Africa outage says no country experienced a total Internet outage because other submarine cables, terrestrial cross-border links, Internet exchange points, and local caches remained available. Yet rerouted links became congested, and some countries experienced severely degraded service for hours. The two damaged cables were repaired by June 3, roughly three weeks later.

The March 2024 West Africa incident was more damaging because four cables near Côte d’Ivoire were affected. The Internet Society documented near-total or degraded connectivity in 13 countries. Operators rerouted traffic across terrestrial links and the unaffected Equiano cable, which experienced a fourfold traffic increase. Individual repair estimates extended from late March into mid-May.

ITU design guidance estimates a one-to-three-week mean time to repair a wet-plant failure, with location, water depth, cable-ship availability, cause, and weather affecting the schedule. Permits, customs, port access, and simultaneous repair demand can stretch it further.

The public may therefore see all three conditions at once:

traffic has successfully rerouted;
Internet service remains slow or unreliable; and
the broken cable will not be physically repaired for weeks.

Can the Entire Internet Reroute at Once?

No. There is no single Internet control room, master route map, or worldwide failover switch.

Each network controls its own routers and decides which routes to accept and prefer. A cable break may be visible immediately to the two routers beside it, seconds later to other routers in the same provider, and later still to networks that depend on BGP withdrawals or indirect signals.

Different sources can take different paths to the same destination. A user in Florida, a user in London, and a user in Nairobi may recover at different times. IPv4 and IPv6 can also behave differently because their route announcements, peering, and available alternates may differ.

Monitoring sites add another delay. A public outage map may wait for enough probes or reports before declaring an incident, while network operators may see optical alarms instantly. Conversely, a routing dashboard can show a new path before applications fully recover.

The phrase the Internet rerouted is therefore shorthand for many local and interdomain decisions reaching a usable state.

How CDNs and Anycast Reduce the Impact

Content delivery networks place copies of content in many locations. Internet exchange points let nearby networks exchange traffic locally. Anycast allows multiple sites to announce the same service address so routing can direct users toward an available instance.

If an international cable fails, a locally cached video, software file, or webpage may remain reachable without crossing the damaged route. A noncached request to a distant origin can still fail or slow down.

RFC 4786 describes withdrawing an anycast service route when a node becomes unavailable so traffic can go to another node. This helps with service and path failures, but the same physical-diversity rules apply. Several data centers advertised under one address do not provide resilience if their external connections share the same cable corridor.

Anycast can also move a user to a farther location after a failure. The service remains available, but latency and session continuity can change. Some existing connections may need to restart because the new request reaches a different server or region.

Why “Two Providers” May Still Be One Physical Path

Buying two Internet services improves resilience only when their failure domains are sufficiently independent.

The providers may:

lease capacity from the same underlying carrier;
enter the building through the same conduit;
cross the same bridge or railway;
terminate in the same street cabinet or central office;
use the same cable landing station;
depend on the same regional long-haul fiber; or
share electrical power, cooling, poles, or rights of way.

Businesses that need continuity ask for route maps, entrance-facility diversity, carrier diversity, separate equipment, and documented service-level objectives. They test failover rather than assuming a second invoice proves a second path. AWS reliability guidance similarly recommends geographically separate data centers and dynamically routed connections for true physical redundancy.

At home, a cellular or satellite backup is more likely to avoid the same buried cable than a second service delivered over the same neighborhood plant. It may still share upstream facilities or power, and its data limits, latency, and indoor signal should be tested before an emergency.

How Long Until Performance Returns to Normal?

Reachability may return before normal performance. A practical sequence is:

Milliseconds to seconds: adjacent equipment detects the cut and activates local protection where available.
Seconds to minutes: internal and external routes reconverge; some sessions reconnect.
Minutes to hours: operators adjust traffic engineering, open additional capacity, or coordinate with other networks.
Hours to days: temporary services, new circuits, or manual workarounds may improve stability.
Days to weeks: crews repair terrestrial or subsea infrastructure, depending on location and access.
After repair: operators restore preferred routes carefully and monitor for errors or congestion.

Returning traffic to the repaired path can itself create a small change. Networks may delay restoration to prevent route flapping, test the cable, balance loads, or wait for a maintenance window.

There is no universal point at which every customer returns to the former latency and speed. A repaired physical cable can also require optical testing, splicing, amplification checks, routing changes, and service validation before full capacity is declared restored.

What Should a Home User Do During a Suspected Cable Cut?

First determine whether the problem is inside the home or beyond it.

Check the equipment indicators. Record the modem, optical-network-terminal, gateway, and router lights before restarting anything. A red optical alarm or loss-of-signal indicator can help the provider diagnose the line.
Test more than one device. A single phone or computer problem is not an Internet cable outage.
Try wired and Wi-Fi access if available. This separates local wireless trouble from loss of provider service.
Check the provider’s official status source. Use cellular data if the home connection is down.
Avoid repeated factory resets. A reset erases settings and cannot repair outside cable damage.
Report visible damage safely. Do not touch a downed cable, enter a work zone, open a pedestal, or look into fiber ends. Contact the provider or appropriate local authority.
Use a separate backup connection. A phone hotspot, fixed-wireless link, or satellite service can bridge the outage if it does not share the same failure.
Preserve outage details. Note the start time, provider messages, ticket number, and service-restoration time.

If emergency calling, medical equipment, security, or work depends on connectivity, plan a backup before an outage. Do not assume ordinary Wi-Fi calling or a battery backup will work when the provider’s upstream path is cut.

How Network Operators Make Rerouting Faster

Fast recovery comes from design and testing:

physically diverse fiber routes and building entrances;
multiple transit and peering relationships;
spare capacity on alternate links;
BFD or reliable lower-layer failure signaling;
precomputed IP or MPLS fast reroute;
carefully tuned routing timers;
shared-risk analysis for ducts, poles, landing stations, and power;
local Internet exchange points and content caches;
anycast and geographically distributed services;
automated monitoring and traffic engineering; and
controlled failover exercises.

Aggressive timers without adequate router capacity and stable links can make a network less reliable. Backup paths that have never carried production-scale traffic may contain configuration errors or insufficient capacity. AWS and other major-network guidance emphasizes testing redundant connections rather than merely installing them.

The strongest design asks two questions: Can traffic reach an alternate path quickly? and Can that path carry the failed path’s load for as long as repairs take?

When Rerouting Cannot Help

Automatic routing is ineffective when:

no alternate physical path exists;
every alternate shares the damaged cable, conduit, or landing point;
backup links are also down;
the destination itself lost power or connectivity;
routing policy rejects the available path;
the replacement path lacks usable capacity;
a misconfiguration prevents advertisements or forwarding;
an application depends on state that cannot survive the path change; or
the damage isolates the customer’s only access line.

In these situations, recovery requires physical repair, manual provisioning, mobile or satellite backup, emergency capacity, or restoration of the destination service. “The Internet was designed to route around damage” is directionally true for redundant networks, but it is not a guarantee for every user or failure.

If you are troubleshooting routing, Wi-Fi, or network recovery, these related guides may also help:

Frequently Asked Questions

Can the Internet reroute around a cut cable instantly?

Not literally instantly. A protected router can shift to a precomputed alternate in tens of milliseconds after detecting the failure. Wider routing changes take longer, and users can lose packets during detection. There is no recovery if no independent alternate path exists.

How long does BGP take to reroute traffic?

BGP changes often become useful within tens of seconds to several minutes, but there is no fixed global timer. Detection method, hold timers, alternate routes, router workload, policy, and the number of affected networks all change the result. Unusual cases can take longer.

Why is my Internet slow if traffic was rerouted?

The alternate path may be longer or lack capacity for the displaced traffic. Queuing, packet loss, and higher latency can continue until operators rebalance traffic, add emergency capacity, or repair the cable.

Does rebooting my router force the Internet to find another route?

No. Carrier and Internet routers make upstream path decisions. Rebooting can resolve a local equipment problem, but it cannot repair cut fiber or create an alternate provider path. Repeated factory resets can make recovery harder by erasing configuration.

Can a video call survive a cable reroute?

It may survive a very fast change, but packet loss, reordering, latency changes, NAT state, or a new server path can freeze or end the call. Reconnecting after routing stabilizes often works even when the original session failed.

How long does it take to repair a submarine Internet cable?

ITU guidance estimates a mean repair time of one to three weeks, depending on the location, water depth, cable-ship availability, damage cause, and weather. Permits, customs, simultaneous faults, and difficult conditions can extend the timeline.

Is a submarine cable cut likely to take down the whole Internet?

No single cable carries the entire Internet. The impact ranges from barely noticeable to a near-total national or regional outage, depending on cable diversity, terrestrial links, local content, available capacity, and whether several cables share the same damaged area.

Why do some websites work while others do not after a cable cut?

Destinations use different networks, data centers, routes, and content caches. Local or cached content may remain available while traffic to a distant origin fails. IPv4 and IPv6 paths can also recover differently.

Does DNS control the cable reroute?

Usually no. Routers use IP routing protocols to move packets around failed paths. DNS can steer some services toward different servers, but ordinary backbone convergence does not require the user to wait for a DNS change.

Can two Internet providers fail from one cable cut?

Yes. They may lease the same underlying fiber, share a conduit, pole route, central office, bridge, landing station, or regional backbone. True resilience requires physical and operational diversity, not merely two company names.

Will active downloads resume after rerouting?

Some applications retry or resume automatically, especially when the address and connection state remain usable. Others restart because the transport session timed out, a new route changed stateful devices, or the server no longer recognizes the connection.

Can satellite service replace a broken submarine cable?

Satellite can provide valuable emergency or backup connectivity, especially for isolated locations, but it generally does not replace the full capacity and latency characteristics of major fiber systems. Availability, terminals, spectrum, cost, and congestion limit how much traffic can move.

How can I see whether my traffic took a new route?

Traceroute can show a changed sequence of visible router hops, but many networks filter, hide, or treat traceroute packets differently. A different trace can support the conclusion that the path changed; an unchanged or incomplete trace does not prove it did not.

Does traffic immediately return to the repaired cable?

Not always. Operators may test the repaired span, restore optical capacity, adjust route preferences, move traffic gradually, and watch for instability. Some flows can remain on alternate paths until routing policies or sessions refresh.

Quick Summary

The Internet can reroute around a broken cable in tens of milliseconds when the nearby router detects the failure and already has a safe, precomputed backup. BFD-assisted detection and local fast-reroute mechanisms can reduce packet loss to a very short interval. Internal routing changes often complete in seconds, while BGP changes between independent networks commonly take tens of seconds to several minutes and occasionally longer.

Rerouting only works when an independent path exists. A second logical circuit that shares the same conduit, landing station, router, or long-haul fiber can fail with the first. A cut last-mile line may leave a home or business completely offline until repair unless it has separately delivered cellular, wireless, satellite, or second-provider service.

Successful rerouting does not guarantee normal performance. Alternate cables may be longer and congested, causing high latency, slow speeds, packet loss, and broken sessions. In major submarine incidents, traffic can move quickly while degraded service continues for hours or days. Physical submarine-cable repair commonly takes weeks; ITU guidance estimates a one-to-three-week mean under ordinary variables.

For users, record equipment indicators, test wired and Wi-Fi connections, check the provider’s official status, avoid unnecessary factory resets, and use an independent backup. For networks, real resilience comes from physical route diversity, spare capacity, fast failure detection, precomputed alternates, sound routing policy, local content, and regular failover testing.

Sources & References

Editorial Review

Reviewed by Claire Bennett, Managing Editor

Last reviewed: August 2026

Quick Answer Guide publishes practical, research-based answers to common questions about money, technology, health, travel, home improvement, and everyday life. Content is reviewed using official government resources, educational institutions, industry publications, and other authoritative sources when appropriate. Articles are updated periodically to improve accuracy and usefulness.

How Long Does It Take for the Internet to Reroute Around a Broken Cable?