Starlink Failover Router Setup Kenya for Customer-Owned Networks

When an office, shop, lodge or remote worksite has two internet connections, a compatible router can be configured to use one as the primary link and the other as a secondary link. SpaceKits provides Starlink failover router setup in Kenya for compatible, customer-owned equipment. The work focuses on configuration, controlled testing and clear handover rather than claims of guaranteed continuity.

SpaceKits is an independent installer and technical service provider. We are not Starlink, a mobile operator, a fibre provider or an authorised representative of a router manufacturer. Each ISP account, subscription, SIM, service address and administrator credential remains under the control of the client or the client’s nominated IT contact. We do not take ownership of those accounts or keep undisclosed administrator access after the job.

Failover is not the same as zero downtime. A router must first detect that the selected primary path is unavailable, decide that the failure meets its rules, and then move new traffic to the secondary path. Existing calls, VPN sessions, payments or cloud connections may reset during that change. The secondary ISP can also be unavailable, congested or restricted at the same time. Our role is to implement a compatible plan, test defined scenarios and document the observed behaviour without promising uninterrupted service.

Customers who need ordinary router configuration without two-link switching should use the Starlink router setup and configuration service. Power continuity is a separate dependency; the existing Starlink backup power guide can help frame a plug-in, customer-owned power discussion without adding fixed electrical work to this service.

Scope: what a failover configuration includes

The service starts with two active internet links and a router that supports the required multi-WAN or failover features. A typical plan may use fibre, fixed wireless or another ISP connection as the primary link and Starlink as the secondary link, or the reverse. The correct order depends on the client’s priorities, service terms, data limits, applications and actual equipment.

An agreed configuration can include:

• identifying and labelling the intended primary and secondary WAN connections;
• confirming that both links work independently before failover logic is introduced;
• checking the exact router model, firmware state, available ports and supported WAN modes;
• setting compatible health checks, detection intervals and recovery behaviour;
• deciding whether the router should return automatically to the primary link when it recovers;
• documenting local addressing, DHCP and approved routing settings;
• performing controlled primary-link and secondary-link tests;
• checking representative client applications after each switch; and
• handing the final configuration record and administrator control to the client or IT contact.

The service does not increase the capacity of either ISP. It does not combine two subscriptions into a guaranteed faster service, and it does not make every application survive a public-IP change. Load balancing, bonded connectivity and application-level redundancy are different designs and are not assumed to be included in a basic failover quote.

Compatibility comes before configuration

The words “dual WAN” on a product listing do not prove that a router will meet a specific continuity requirement. The exact hardware revision, firmware, number and type of usable ports, Starlink connection method, licensing and client network must be checked. Some routers support simple link switching but not policy routing, detailed health checks or a preferred recovery delay. Some third-party arrangements require a compatible customer-supplied adapter or supported bypass mode.

Both internet links must also be suitable for the client’s applications. A secondary connection may use carrier-grade NAT, a different public address, a data cap or an ISP policy that affects inbound services and VPNs. The client’s IT contact should identify any application that depends on a fixed source address, allow-list, persistent tunnel or remote-access rule before the work begins.

SpaceKits configures only compatible customer-owned equipment. If a required feature is absent, we document the gap rather than applying unsupported firmware, inventing compatibility or promising that an untested device will work.

Primary and secondary link plan

A useful failover plan names each link and states what should happen. For example, the client may select fibre as primary and Starlink as secondary during a fibre outage. Another remote property may select Starlink as primary and a mobile router as secondary. The quote and handover should use those exact roles instead of vague labels such as “main internet.”

The plan should also define:

• what the router will test to decide that a link is healthy;
• how long a failed test must continue before switching;
• whether recovery requires several successful checks;
• whether traffic should return to the primary link automatically or only after review;
• which client devices or applications are included in the test; and
• who approves changes during business hours.

These choices balance two different risks. Switching too quickly can cause unnecessary interruptions during a brief network fluctuation. Switching too slowly can leave users waiting on a failed path. There is no universal timer that is correct for every ISP, router and business workflow.

Configuration and test process

1. Account and equipment ownership

The client confirms ownership or written authority for both ISP accounts and all routers being configured. The account owner signs in personally where an app or portal is required. Passwords, SIM PINs, recovery codes and billing details should not be placed in a public message or retained by the technician.

2. Baseline each connection

Each link is connected and tested independently before it becomes part of the failover plan. We record whether ordinary browsing and agreed applications work, the connection method, and any visible ISP or hardware limitation. A speed reading can be noted as a moment-in-time observation, but it is not a promised future speed.

3. Record and protect the existing network

The existing LAN, network names, addressing and critical devices are documented. Where practical, a customer-controlled backup of supported router settings is made before changes. This creates a rollback reference if a new rule conflicts with the client’s environment.

4. Apply the approved rules

Primary and secondary ports, supported health checks, switching thresholds and recovery rules are configured on the compatible router. Only the agreed scope is changed. Security systems, CCTV, fixed wiring and unrelated application administration are excluded.

5. Run a controlled test plan

With the client or IT contact aware, we test normal primary-link operation, simulate loss of the primary connection using an agreed safe method, observe the switch, check representative applications, restore the primary link and observe the chosen recovery behaviour. We then test how the router reports a secondary-link failure. The test record notes interruptions and applications that need manual reconnection.

6. Handover and owner acceptance

The client receives the final role of each link, settings summary, observed switching behaviour, limitations and rollback information. Administrator credentials remain client-owned. Any dependency on an ISP, application provider or equipment vendor is clearly identified for follow-up.

Quote inputs we need

There is no responsible fixed price for every failover setup because the equipment, business risk and testing requirements differ. For a useful written quote, provide:

• the town and property type;
• the exact router make, model, hardware revision and current firmware where known;
• the primary and proposed secondary ISP connection types;
• the Starlink kit generation and available connection adapter or Ethernet port;
• the preferred primary/secondary order;
• the applications that matter during an outage, such as cloud work, VoIP, VPN or POS;
• the acceptable test window and the nominated decision-maker;
• whether an IT provider already manages the network;
• the number of representative devices to test; and
• photographs of the existing equipment without passwords, private IP plans, serial numbers or account details.

The quote should state configuration assumptions, included tests, client responsibilities and exclusions. Hardware or accessories should not be assumed available until their exact compatibility and ownership are confirmed.

Exclusions and important limitations

This is a configuration-and-testing service for compatible customer-owned equipment. It excludes solar work, electrical installation, new sockets, fixed wiring, structured or fibre cabling, point-to-point links, roof work, CCTV and other security systems. It does not include ISP account transfer, plan purchase, SIM registration, unsupported firmware, hidden remote access or ongoing network monitoring unless separately and lawfully agreed.

SpaceKits does not guarantee zero downtime, uninterrupted calls, preserved VPN sessions, a fixed public IP, a specific switching time, speed, uptime, coverage or search ranking. We cannot guarantee that two independent ISPs will not fail simultaneously. The client remains responsible for ISP bills, data limits, account recovery and application-provider requirements.

Frequently asked questions

1. Can Starlink be the backup connection for my fibre internet?

Yes, if both links are active and the customer-owned router supports a compatible failover design. The exact connection method, router features and application requirements must be checked before configuration.

2. Can Starlink be the primary link instead?

Yes. The client may choose Starlink as primary and another compatible ISP as secondary. The written plan should name those roles and define when the router should switch and recover.

3. Does failover mean there will be zero downtime?

No. Detection and switching take time, and active calls, VPNs or payments may reset when the public path changes. We test and document observed behaviour but do not promise seamless or uninterrupted service.

4. Do you need my ISP passwords?

The client or authorised IT contact should sign in when account access is required. Credentials and recovery details remain client-owned and should not be sent through public forms or retained after handover.

5. Can any dual-WAN router be used?

No. Hardware revision, firmware, ports, licensing, health-check features and the Starlink connection method all affect compatibility. The exact models must be reviewed first.

6. Will failover combine both links for higher speed?

Not in a basic failover setup. Failover selects an available path according to agreed rules. Load balancing or bonded connectivity is a different design and requires separate compatibility and scope assessment.

7. What tests are performed?

The agreed plan normally checks each link independently, normal primary operation, controlled primary loss, secondary operation, primary recovery and representative applications. Results and any manual recovery steps are documented.

8. Does the service include cabling or electrical work?

No. It covers compatible router configuration and testing only. Fixed electrical work, structured or fibre cabling, point-to-point links and building alterations require separate, appropriately qualified providers.

Request a failover configuration assessment

Use the SpaceKits contact page to provide the equipment models, both ISP types, preferred primary link and critical applications. Do not send passwords. We will confirm whether the equipment supports the intended plan and describe the configuration, test cases, client responsibilities and limitations in the quote.