Ways to Reduce the Risk of Internet Downtime
Treat resilience as a planned business decision
An unreliable connection, dependence on one service or uncertainty about backup can create real business risk. The right response starts with the work the connection supports and the interruption the organization can tolerate—not with an assumption that every business needs another provider, more bandwidth or SD-WAN.
This article is for planning a connectivity decision. If service is down now, use the support process established with your internet provider and IT team for diagnosis and restoration. Caisson can help evaluate the longer-term business decision and coordinate agreed provider conversations, but does not operate a help desk, monitor the network or restore service.
Decide what must keep working
Identify the functions that depend on connectivity before comparing solutions: customer calls, payment processing, cloud applications, remote access, video meetings, site-to-site traffic or other critical work. Separate what must continue from what could pause or operate in a reduced mode.
Ask:
How would an interruption affect customers, employees, revenue or essential operations?
How long could each critical function be unavailable or degraded?
What minimum capacity would those functions require during a disruption?
Could people use an approved manual or alternate process for a limited period?
Who has authority to set the tolerance, approve the budget and accept the remaining risk?
These answers define the business requirement and prevent a backup option from being judged only by advertised speed or features.
Is this a primary-service problem or a continuity gap?
Poor performance does not identify its own cause. The issue could involve inadequate capacity, provider service, a firewall or router, Wi-Fi, power, an application or another dependency. A second connection will not correct every condition.
A primary-service review asks whether the current connection suits normal operation. A continuity review asks what should happen when a relevant component degrades or fails. The organization may need one review or both.
Use information from the responsible provider and technical team to separate facts from assumptions. If the cause or service boundary is unclear, verify it before purchasing. Caisson can frame the questions and compare alternatives; technical diagnosis and testing remain with the responsible provider, IT team or specialist.
Schedule a Technology Assessment
What happens in a Technology Assessment?
Retain, improve, add or verify
The appropriate path may be smaller than a full replacement:
Retain: Keep the current arrangement when it meets the normal operating requirement and the accepted continuity need.
Improve or replace the primary service: Consider a different capacity, service type or provider when evidence shows the connection no longer fits. More bandwidth may address capacity, but it does not create an alternate path.
Add limited backup: A second wired or wireless connection may support defined critical work when its capacity, dependencies and operating method fit the requirement.
Consider more capable routing or SD-WAN: These may deserve evaluation for more complex application, performance or multi-location needs. SD-WAN is not required simply because backup is needed.
Verify first: Pause the purchase when the cause of the problem, available paths, equipment behavior or provider responsibility could change the recommendation.
A no-purchase outcome may be appropriate when the current arrangement meets the requirement or when the responsible team should correct or verify an existing issue first.
Fiber describes an access medium. It does not establish that service is dedicated, diverse or more reliable, or that a particular SLA applies. Compare the actual service, responsibilities, cost and terms.
Business Internet
SD-WAN Services
Ask what the alternative path would actually protect
An additional circuit is an additional connection. Calling it redundant requires understanding the failure being addressed and shared dependencies. Two provider names do not prove independent infrastructure.
Where relevant, ask the providers and technical team to clarify:
the underlying access providers, physical routes, building entrances, risers and handoff equipment;
power required by provider and customer equipment, and the scope of any backup power;
the firewall, router, switching and configuration needed to use the alternate connection;
addressing, VPN, allowlist, voice, payment and cloud-application dependencies;
usable backup capacity, wireless coverage or congestion limits, data restrictions and site conditions;
how failure or degradation is detected, how traffic moves, and what happens when the primary path returns.
Record unavailable information and residual risk instead of describing the design as fully diverse.
Failover moves traffic to another path after a defined condition. Load balancing distributes traffic across available connections during normal use. Either may involve interruption, a changed public address or application effects. Session preservation, combined bandwidth and return to the primary path depend on the services, equipment and configuration; confirm and test them rather than promise them.
Connectivity resilience does not provide data backup, application recovery, disaster recovery or cybersecurity operations. Those needs require their own owners and plans.
Assign responsibilities and compare commitments
The exact allocation depends on the services and agreed scopes, but each material responsibility needs a named owner.
| Party | Responsibility to establish |
|---|---|
| Client leadership | Critical functions, tolerable interruption, budget, risk acceptance and final commercial decisions |
| Caisson | Clarify objectives, evaluate alternatives, explain trade-offs, recommend an appropriate path and coordinate agreed commercial, provider and implementation decisions |
| Internet and network providers | Confirm service scope, availability, delivery, support, service boundaries and restoration obligations under their agreements |
| IT team, MSP or integrator | Design, configure, test, monitor, maintain and support the customer-side environment within its agreed scope |
| Building, power or other specialists | Complete the physical access, power, cabling or specialist work assigned to them |
Review costs, equipment and licensing, contract terms, support routes and operating responsibilities together. An SLA may define commitments, measurement rules, exclusions and remedies for a particular service. A credit does not prevent an outage or replace a continuity plan, and no universal restoration interval should be assumed.
If the decision is connected to a renewal, contract or provider comparison, review the actual agreements and proposals before committing.
Define readiness and contingencies before relying on the design
A backup arrangement becomes useful only when it is prepared for the work it must support. Agree what will be validated, who will do the work, who records issues and who accepts the result.
Cover the relevant failure or degradation conditions, critical applications, minimum capacity, transition behavior and return to normal operation. Confirm support routes. Decide what the business will do if the alternate connection, local equipment, power or a critical application is also unavailable.
Testing and maintenance should reflect the actual environment and be performed by the appointed technical resources. Shared dependencies and residual risk can remain even in a well-designed arrangement. The aim is an understood level of protection, clear ownership and a feasible response.
Start with a focused advisory conversation
Caisson serves as the Independent Technology Advisor. We begin with the business objectives, current arrangement and continuity concern; evaluate appropriate alternatives; explain the trade-offs; recommend a path; and help coordinate agreed decisions with the providers and technical teams responsible for delivery. Keeping the current service, making a limited change or verifying the environment before buying are all valid outcomes.
The initial Technology Assessment is approximately a 30-minute business conversation with Brian Wade. It is a way to understand the situation, clarify priorities and identify an appropriate next step. Scheduling does not include troubleshooting, technical testing, an outage investigation, a resilience audit, packet or path analysis, written reporting, provider escalation, implementation planning, emergency restoration or ongoing monitoring. Any deeper work is separately scoped.
If available, bring the locations, current providers, business effect and any relevant renewal or decision date. A complete technical inventory is not required.