Skip to main content

Too many redirects or redirect loop

Find and correct redirect chains that exceed the monitoring limit, repeat, omit a destination, or lead to an unsafe target.

A redirect failure means the monitored URL did not reach a final response through a valid redirect chain. Uptime Basics labels redirect-limit and related redirect failures Redirect loop.

With Follow redirects enabled, an availability check follows HTTP 301, 302, 303, 307, and 308 responses. It follows up to five redirects and uses one overall timeout budget for the complete chain.

Common redirect problems

  • HTTP redirects to HTTPS and another rule redirects back to HTTP.
  • www redirects to non-www while a second layer reverses it.
  • A trailing-slash or capitalization rule repeats.
  • A CDN and origin each enforce a different canonical URL.
  • A login route returns users to the same login route.
  • A redirect response is missing a valid Location destination.
  • The chain contains more than five intentional redirects.
  • A destination has its own DNS, TLS, timeout, or HTTP failure.

Inspect the complete chain

  1. Open Detailed Logs and confirm the Redirect loop diagnosis.
  2. Copy the exact monitored URL.
  3. Use a browser network panel or HTTP inspection tool that displays every redirect.
  4. Write down each status code and Location destination in order.
  5. Compare rules at the CDN, load balancer, web server, application, and origin.
  6. Remove the first rule that returns to an earlier URL or an unnecessary intermediate step.

Test without browser cookies when possible. A signed-in browser can follow a different path from an independent monitor.

The five-redirect limit

If the chain is valid but longer than five redirects, simplify it or monitor the final stable URL directly. Long chains add latency, consume the request timeout, and add more points where DNS, TLS, routing, or application behavior can fail.

Every redirect destination must remain a public HTTP or HTTPS target on an allowed port. Uptime Basics resolves and validates each destination before requesting it.

Protected redirects

Basic Authentication and custom request headers are retained for redirects on the same origin. When a redirect changes origin, sensitive credentials and custom headers are removed.

If both origins require authorization, monitor the final approved URL directly or redesign the health endpoint. Do not put credentials in the URL or query string.

If redirect following is turned off

With Follow redirects disabled, Uptime Basics records the first redirect response and does not test its destination. Because a normal 3xx response is accepted by default, the monitor can remain Up even if the destination is unavailable.

Turn redirect following off only when the redirect response itself is the behavior you need to monitor.

After correcting the chain

Leave the monitor active and allow the next check to run. A successful result resets pending failures or resolves the incident. Earlier redirect failures remain in Detailed Logs until normal retention removes them.

When to contact Support

Contact Support if an independent HTTP tool shows five or fewer valid redirects but Uptime Basics continues to report a redirect failure.

Include the monitor name, starting URL, timestamp, redirect setting, and a sanitized list of status codes and destinations. Do not include authorization values, session cookies, passwords, signed URLs, or private query parameters.

Related articles

Did this answer your question?

Your response helps improve this Help Center.