Hoppla walks your URL's redirect chain the way a browser would, up to 10 hops, logging each hop's status code, Location header, and response time. It catches the chain that loops back on itself, the https that quietly drops to http, the 302 sitting where a permanent 301 belongs, and the hop count that drags every cold visit. One thing it won't do: dress a long chain up as a downtime incident. This check warns and informs: a new finding arrives once as a warning, never as an outage page.
acme.io 301 → www 302 → https 200 · 2 hops · 88ms total · WARN: 302 should be 301
Fictional values. Not a live measurement.
Hoppla starts at your URL and follows each redirect in turn, up to 10 hops, recording the status code, the Location header, and how long each hop took, plus the total time for the whole walk. Then it reads the chain back for trouble: a loop, an https-to-http downgrade, a missing Location, a final 4xx or 5xx, or a 302 sitting where a permanent 301 is the right answer. You see the whole path the browser walks, not just where it lands.
Hoppla requests your URL and reads the response without auto-following the redirect. It records the status code, the Location header it was told to go to, and the time that hop took, then steps to the next URL and does it again. Hard ceiling: 10 hops.
Each hop is timed on its own and the whole walk gets a total, so you can tell one slow hop apart from a long chain. Any hop slower than 500ms gets an info-level note. The chain that loads fine but drags gets surfaced instead of buried.
Hoppla reads the recorded chain against fixed rules. A loop, more than 10 hops, an https-to-http downgrade, a missing Location, or a final 4xx/5xx is FAIL-class. A chain longer than 3 hops, or an http-to-https move done with a 302/307 where a 301 belongs, is a WARNING. Temporary, 308, external, and slow hops are logged as info-level notes.
The result is advisory. A broken or bloated chain shows up as a warning on the monitor with the full per-hop breakdown, so you can read exactly which hop downgraded or looped. No downtime incident, no outage page. A redirect problem is a hygiene finding, not a 3 a.m. emergency.
A redirect that points back at itself burns the request and serves nothing. Hoppla caps the walk at 10 hops and names the loop outright, so the page that 'sometimes won't load' stops being a mystery. It's one line in the chain, and you can fix it.
A chain that drops from https to http mid-hop strips the connection's protection and trips browser warnings, and the final padlock never lets on that it happened. Hoppla reads the protocol of every hop, so a downgrade is flagged as a FAIL-class finding on the first run that sees it.
A temporary 302 or 307 tells search engines the move is provisional, so they may keep the old URL indexed and its ranking signals there. Use one where a permanent 301 is correct, and the move can take longer to stick. When an http-to-https redirect makes that mistake, Hoppla warns you; other 302s get an info-level note.
You moved your marketing site to a new path months ago, wired up the redirect, and forgot it. What you never saw: it became a 302 stacked on a www-to-apex hop stacked on an http-to-https hop. Three redirects deep, adding latency to every cold visit and possibly holding ranking signal at the old URL. Hoppla shows you the chain hop by hop, flags the 302 with a note that a permanent move wants a 301, and you collapse three hops into one clean permanent redirect in an afternoon.
A client just migrated to a new domain and your job is to prove the redirects are clean before you call it done. Point Hoppla at the old URLs and read the chains: each one should land on its new home in a single 301, https the whole way, no downgrade and no detour. The run that comes back with a stray 302 or an https-to-http hop is the one you fix before it can cost the client organic traffic.
Nobody hand-audits redirect hygiene across hundreds of client URLs. Add the redirect check to the monitors you already run and every URL's chain is read on schedule, with the findings surfacing across the fleet: the four-hop chains, the stray 302s, the one downgrade hiding in a thousand clean paths. Account managers walk into a review with 'here's the chain, here's the fix' instead of hearing about it after a ranking drop.
Migrations are when customers are most willing to pay for someone to get it right, and redirect hygiene is the natural add-on to that work. Under your own brand and domain, bundle a redirect-chain audit into every migration: confirm each old URL lands on a single, permanent, https-clean redirect before sign-off. It runs on the platform you already resell, so it's a new line item with nothing to build and your name on the report.
Import the monitors you already run in another tool. What comes across depends on the provider. Run both side by side for 24 hours or 7 days before you switch.
The importer opens in your workspace once you have access.
Get early accesscurl -IL does follow the chain and print the headers. Once, from your laptop, when you remember to run it. The redirect check runs on schedule against every monitored URL, classifies what it finds (loop, downgrade, 302-where-301-belongs, too many hops), and records per-hop timing plus a total. You get a warning when a redirect breaks (checked every 12 hours by default), instead of finding out next time you happen to type the command.
No. This check is advisory. A loop, a downgrade, or a four-hop chain shows up as a warning on the monitor with the full per-hop breakdown. It never opens a downtime incident; a new finding is sent once as a warning, not as an outage alert. If you want to be alerted that a URL is unreachable, that's the uptime check's job. This one is about hygiene, not outages.
Because search engines treat them differently. A permanent 301 passes ranking signal to the destination; a temporary 302 or 307 tells engines the move is provisional and to keep the equity at the old URL. When an http-to-https redirect uses a 302/307 where a 301 is correct, Hoppla warns you, because that one wrong status code can quietly cost you SEO.
FAIL-class: a redirect loop, more than 10 hops, an https-to-http protocol downgrade, a missing Location header, or a final 4xx/5xx. WARNING: a chain longer than 3 hops, or an http-to-https move done with a 302/307 instead of a 301. Temporary, 308, external, and slow (>500ms) hops are logged as info-level notes, not problems.
Checks, alerts and status pages in one workspace. Now in early access: join the list for an invite.