Question 1

How is this different from DNS-level failover?

Accepted Answer

It covers what DNS can't. DNS or anycast failover is the right tool when your server dies and your domain still resolves — use it, and keep using it. But it runs on the domain, so it can't help when the domain is the thing that broke: an expired registration, a registrar dispute, a nameserver you no longer control, a migration that repointed the zone at nothing. In those cases there is no record left to fail over. LastRedirect lives in the visitor's browser instead, so it still works when your DNS doesn't.

Question 2

Which failures does it actually catch?

Accepted Answer

Our end-to-end suite runs these against Chrome, Firefox and Safari on every change. A server refusing connections, an origin returning 5xx, and a domain that stops resolving all send the returning visitor to your backup. A 4xx is passed straight through untouched — that's your origin answering correctly about one page, and failing every 404 over to a backup would be worse than useless. We also verify that a worker installed before a full browser restart still fails over afterwards.

Question 3

Will the worker still be installed weeks later, when I actually need it?

Accepted Answer

Sometimes, and it depends on the browser — this is the honest ceiling on what we do. A registration is persistent storage and survives a full browser restart, which our test suite verifies on Chrome, Firefox and Safari. But WebKit caps script-writable storage at seven days without a first-party interaction, and Chromium evicts under storage pressure, so a visitor who last came two months ago on an iPhone may well have nothing installed. When the registration is gone there is no failover at all — the visitor gets the browser's own error page. Every successful visit re-arms it, so the more often someone visits, the more reliably they're covered.

Question 4

What happens if LastRedirect goes down?

Accepted Answer

Your site keeps serving exactly as it does now. Every navigation goes to your origin first and never blocks on us — the worker only needs our answer once that request has already failed, and if it can't reach us it passes your origin's own response straight through. We are never in the path of a working request, so an outage on our side cannot slow down, block, or break a page load. The honest limit: if our API and your origin are both unreachable at the same moment and the worker has no cached config, the failover redirect won't fire — you get today's behaviour, not something worse.

Question 5

What does my site need for this to work?

Accepted Answer

HTTPS on your own origin (service workers require a secure context), a browser that supports service workers, and the ability to serve one file from your domain root — that's what gives the worker site-wide scope. Platforms that only serve uploaded assets from a separate CDN origin or a non-root path, such as Shopify, Webflow and BigCommerce on standard hosting, can't provide that scope and aren't supported.

Question 6

Does this replace uptime monitoring?

Accepted Answer

No — it complements it. Monitoring tells you something is wrong; LastRedirect keeps the visitor moving while you fix it.

Question 7

Does it help first-time visitors?

Accepted Answer

No, by design. Only visitors who previously loaded your site with the script installed get redirected. It's a floor under the infrastructure failover you already run, not a replacement for it, and not an acquisition channel.

Question 8

What if I don't have a backup site set up?

Accepted Answer

You need to configure one — a static page on a different domain and host is enough. The point is that it must not share the failure you're insuring against: a different registrar and provider than the origin it backs up.

Question 9

What does the script collect about my visitors?

Accepted Answer

It sets no cookies and does not follow anyone between sites. On install and on a failover it reports the entry path — query strings and fragments stripped — and from that request we derive a truncated IP, coarse location, network and device, which is what the per-site statistics in your dashboard are built from. Those records are deleted automatically after 30 days.

Question 10

Does this affect SEO or crawling?

Accepted Answer

No. The service worker only intercepts client-side navigation failures; it has no effect on how search engines crawl or index your site.

Failover for the outages DNS can't reach.

The problem

Every failover you own runs on the domain. So none of them survive losing it.

How it works

Five steps, entirely in the browser.

What you get

Built for developers who already did the infrastructure work.

Our pricing

Plans and pricing

Security & privacy

You're handing a script control over navigation. Here's exactly what it can do.

Questions

Common questions.

We can help

Get in touch