ObserveifyNowOpen workspace
Understand a monitor response without probing a website. Search common standardized codes, their classes and the limits of what they tell you.
Free and account-free. Filtering stays in memory: no URL checks, saved searches or input sent over the network. Source links open documentation only when you follow them.
Search words across the name, explanation and example. Combine words with a class filter. This is a curated selection, not the full registry.
20 reference entries. Browse all five status classes below.
The server invites the client to send the request body.
What it cannot establish: An interim response is not a completed request.
Example: An upload receives 100 before the final response.
Read the specification for 100The server agrees to switch protocols as requested by the client.
What it cannot establish: A protocol switch does not establish later application health.
Example: An HTTP connection upgrades to another protocol.
Read the specification for 101The request succeeded; its meaning depends on the request method.
What it cannot establish: A 200 response is not proof of correct content or a healthy application.
Example: A login page returned to a monitor can still carry 200.
Read the specification for 200The request created one or more resources.
What it cannot establish: Creation does not prove later processing or dependencies succeeded.
Example: An API creates a new job resource.
Read the specification for 201Processing was accepted but is not complete.
What it cannot establish: The work can still fail after this response.
Example: A queued report is accepted, not yet generated.
Read the specification for 202The request succeeded with no response content.
What it cannot establish: An empty body is expected, not proof that a page failed.
Example: An update succeeds without a response body.
Read the specification for 204The resource has a new permanent URI.
What it cannot establish: A redirect alone does not prove the destination works; some clients change POST to GET.
Example: An old documentation path redirects to its replacement.
Read the specification for 301A conditional GET or HEAD can reuse a stored representation.
What it cannot establish: This is cache validation, not a fresh response body or broad health check.
Example: A matching ETag allows reuse of cached content.
Read the specification for 304Repeat the request at another URI without changing the method.
What it cannot establish: The original URI remains relevant; destination success is unknown.
Example: A POST temporarily moves to another endpoint.
Read the specification for 307Use the permanent replacement URI without changing the method.
What it cannot establish: Check the destination separately; a redirect is not its result.
Example: An API moves permanently while preserving POST.
Read the specification for 308The server rejects what it perceives as a client error.
What it cannot establish: It does not identify which input or intermediary caused the problem.
Example: Malformed request syntax is rejected.
Read the specification for 400The request lacks valid authentication credentials for this resource.
What it cannot establish: Check the WWW-Authenticate challenge; this differs from a 403 refusal.
Example: A protected endpoint receives no valid credentials.
Read the specification for 401The server understood the request but refuses to fulfill it.
What it cannot establish: The refusal can be unrelated to credentials; repeating them may not help.
Example: An access policy denies this request.
Read the specification for 403No current representation was found, or the server will not disclose one.
What it cannot establish: It does not prove the whole service is down or the absence permanent.
Example: A monitor targets a path that no longer exists.
Read the specification for 404The server did not receive a complete request in time.
What it cannot establish: This concerns receiving the request, unlike a 504 upstream response timeout.
Example: The client sends the request too slowly.
Read the specification for 408The user sent too many requests in a given time.
What it cannot establish: Retry-After may specify a wait; limits and user identification depend on the service.
Example: A polling client exceeds an API rate limit.
Read the specification for 429An unexpected server condition prevented fulfillment.
What it cannot establish: The status alone does not identify the failing component.
Example: An application encounters an unhandled error.
Read the specification for 500A gateway or proxy received an invalid upstream response.
What it cannot establish: It does not by itself prove the origin is down or identify the invalid response.
Example: A proxy cannot use the response from an upstream service.
Read the specification for 502The server is temporarily unable to handle the request.
What it cannot establish: Overload or maintenance can cause it; Retry-After may be supplied, not guaranteed.
Example: A service rejects requests during maintenance.
Read the specification for 503A gateway or proxy did not receive an upstream response in time.
What it cannot establish: A timeout does not identify the root cause or prove every upstream is down.
Example: A proxy waits too long for a dependency.
Read the specification for 504A status describes one HTTP exchange from the responding server or intermediary. A 200 can contain the wrong page; a 401 can mean your monitor lacks credentials; a 503 can be a maintenance response. Match the method, expected content, redirects and observation time to the monitor's purpose.
DNS, TLS and connection failures can happen before any HTTP response. They do not have an HTTP status code. One response does not measure uptime, prove a global outage or locate the failed dependency. Check authorized logs and monitoring context before changing infrastructure.
The class groups are 1xx informational responses, 2xx success, 3xx redirection, 4xx client errors and 5xx server errors. These are protocol categories, not a judgment of who caused an incident.
Codes such as 499, 520, 522 and 524 are not standardized entries in the IANA HTTP status registry checked on 20 October 2026. A proxy or vendor may assign its own meaning. Identify the component that emitted the response and consult its documentation; do not apply a vendor meaning to every service using that number.
An unlisted search result remains unknown here. Even a registered code may be outside this short reference; absence does not prove it is unassigned.
Consult the authoritative IANA HTTP status registry. Individual entries above link to RFC 9110 or RFC 6585. Summaries and illustrative examples were reviewed on 20 October 2026.
ObserveifyNow can read a published Uptime Kuma status page directly from your browser without an account, when the service permits browser access. It does not probe arbitrary websites from this reference. Native infrastructure connections and reads are free; confirmed remote mutations require a verified Pro entitlement.
Connect a published status page or calculate an uptime budget.