Why will a server not open, or why does readiness show an error?
Diagnose endpoint selection, disabled URL controls, HTTP error codes, redirects, and TLS failures.
In this article
Start with the selected endpoint
- Open the server's Details… window and find Endpoints.
- Select a current Address and the service's actual Protocol.
- Read the constructed URL before clicking Open or Copy URL.
Other has no automatic browser endpoint. Until you explicitly choose an Address, Copy URL and readiness are disabled, and the card's main action opens Details. If the saved endpoint no longer exists, select a new one. A recognized tool can fall back to its first available address; check which URL is now shown.
Open is unavailable when that identity is no longer in the visible monitored set. Check the current panel for a restart or ignored project. Copy URL may still copy a retained address from an old Details window; copying does not validate that it is still live.
Selecting HTTP or HTTPS does not reconfigure your development server. It only changes the URL Radar opens and probes. Switching to HTTPS for a plain HTTP server will not enable TLS.
If readiness says No HTTP response
- Confirm the terminal still shows the intended server running and listening.
- Check the port and address in Details against your tool's current output.
- Check HTTP versus HTTPS. Port numbers alone do not determine the protocol.
- Try that exact URL in your browser and inspect its result or certificate error.
- If you changed a choice, wait for a new readiness result after a successful scan.
Radar's HEAD check has a 2-second request timeout and a 3-second overall resource timeout. A slow endpoint can fail even if a longer browser visit succeeds. A non-HTTP TCP service can be detected and stopped without ever producing an HTTP response.
Radar does not use browser cookies, stored credentials, or browser-approved TLS exceptions. It also has no custom probe-path, timeout, certificate override, or authentication setting. Fix the underlying endpoint or use the result as a limited reachability clue.
If readiness reports an HTTP error or redirect
| Example | What Radar has verified | What to inspect next |
|---|---|---|
| HTTP 200 or HTTP 204 | The selected endpoint responded to HEAD | Confirm the page or API behavior in your development tools |
| HTTP 301 or HTTP 302 | The original endpoint returned a redirect | Open the URL in a browser; Radar does not follow the destination |
| HTTP 401 or HTTP 403 | An HTTP server responded with an access error | Check application authentication/access rules |
| HTTP 404 | The base endpoint returned a missing-resource response | Check your intended route; Radar has no custom path field |
| HTTP 405 | The server responded but rejected the HEAD method | Check its handling of HEAD rather than assuming no server is listening |
| HTTP 500 | The endpoint responded with a server error | Check the application's own logs and errors |
Radar reports all these as HTTP responses. It does not classify 2xx as healthy and other codes as unhealthy. Redirects are left unfollowed, and invalid TLS is not accepted.
If HTTPS works in the browser but not in Radar
A browser may have a certificate exception or a different hostname. Radar uses the selected IP endpoint and normal TLS validation. A certificate valid for localhost may not be valid for 127.0.0.1 or ::1; a browser exception does not transfer to Radar.
Check the exact URL, certificate validity, and your development server's TLS configuration. Radar does not provide a hostname override or a “trust this certificate” control. Choose HTTP only when your server actually supports HTTP and that is the connection you intend to test.
Wildcard binds are translated for local access: 0.0.0.0 becomes 127.0.0.1, and :: becomes ::1. Specific IP addresses stay as selected. These conversions explain why the picker text and browser URL can differ.
If Checking… or an old result stays on screen
Readiness is scheduled on successful server scans, with at least 30 seconds between checks per server and no more than four checks in progress at once. A 60-second background scan choice can make readiness less frequent than the toggle's 30-second label suggests.
Check that the project is still monitored, readiness is on, and the header has no scan warning. Sleep cancels checks. The status can be cleared when you change project preferences, and a stopped server has no new checks. Reopen the panel for a fresh server scan and allow the next scheduled check to complete.