HTTP Status Code Basics: What 200/301/403/500 Actually Mean for Maintenance Tools

WordPress site maintenance constantly involves one basic question: after an update, is the site still working? Instead of relying on a human eyeballing a page and deciding “looks fine,” most tooling answers that question mechanically, using the three-digit HTTP status code a web server returns for every request. That single number carries more information than it looks like at first glance.

Note: An HTTP status code is a three-digit number a web server always attaches to its response to a client (a browser or a program). It comes paired with a short phrase describing what it means, like 200 OK.

The leading digit sets the broad category

The hundreds digit of a status code determines its broad meaning.

Even this broad grouping alone enables a first-pass judgment: “2xx generally means ignore it,” “5xx always means investigate.” Automated monitoring in maintenance tooling starts from exactly this coarse filter before looking any closer.

Codes you actually run into during maintenance work

Within those broad categories, a handful of specific codes show up constantly in maintenance work.

• 200 OK — the request succeeded and normal content was returned. The baseline “everything is fine” state
• 301 Moved Permanently — the requested URL has permanently moved to a different URL. Browsers automatically follow this to the new location. In WordPress this shows up when unifying http to https, or after a URL structure change
• 403 Forbidden — the server understood the request but is explicitly refusing to grant access. This isn’t a login prompt; it’s a deliberate “you may not see this.” It typically shows up on sites protected by IP restrictions or Basic Auth when accessed unexpectedly
• 404 Not Found — the requested page doesn’t exist. A classic case is following an old link to a post whose URL has since changed
• 500 Internal Server Error — the server hit an unexpected failure while processing the request. This is frequently how a PHP Fatal Error (a syntax error, a call to an undefined function, exhausted memory) surfaces externally, and it’s one of the codes WordPress maintenance work watches for most closely

These numbers come from an RFC (a published internet technical standard), so they mean the same thing regardless of which server software or programming language produced the response — a genuinely shared vocabulary across the entire web.

A sixth status: “0”

In practical monitoring code, you’ll often see a special value alongside the standard 1xx–5xx range: 0. This isn’t part of the HTTP specification — it’s a convention monitoring scripts use to represent no response came back at all. DNS resolution failure, connection timeout, an SSL certificate error — anything that fails before the request even reaches the server lands here.

A server explicitly saying “500” and a server saying nothing at all point to very different root causes, so keeping these two cases distinct matters for how monitoring logic is designed.

A real example: deciding whether to roll back by comparing before and after

This app updates WordPress core and plugins one item at a time, checking the HTTP status right after each individual update to decide whether things got worse — and if so, rolling back only that one update. The decision logic lives in a function called _should_rollback() in maintenance_agent.py, and it can be simplified to this:

def _should_rollback(post_status, prev_status):
    post = int(post_status)
    prev = int(prev_status) if prev_status is not None else 200

    # Server-level failure always triggers a rollback
    if post >= 500 or post == 0:
        return True
    # 4xx regression: only fires if the previous state was below 4xx
    if 400 <= post < 500 and prev < 400:
        return True
    return False

The categories above map directly onto this decision.

• 500-range or 0 (no response) always triggers a rollback, regardless of what came before. That’s a server-level failure, and it’s an unambiguous regression no matter what the prior state was
• 400-range only triggers a rollback if the previous state was below 400. This isn’t a blanket “any 4xx means fail” rule, and there’s a reason: some maintained sites deliberately sit behind Basic Auth (401) or IP restrictions (403) — staging environments, for instance. If the check simply flagged any post-update 4xx as a failure, a site that already returned 401 before the update would trigger a false rollback on every single run, even though nothing actually changed. By judging “did this get worse compared to right before,” a site’s own deliberate baseline state gets correctly treated as normal, not as a problem

The function that supplies post_status — _http_status_check_stable() — adds one more layer: it only retries, once, after a short delay, when the status comes back as 0 (no response). The intent is to avoid misreading a brief network blip or a momentary TLS handshake failure as the site being down, which would otherwise trigger an unnecessary rollback. A 500-range response, by contrast, isn’t retried — it’s treated as a real error immediately. The distinction is between “an uncertain state where we genuinely don’t know yet” and “the server is explicitly telling us something is wrong,” and the code treats those two situations differently on purpose.

Why this matters for maintenance tooling

Reading this three-digit number mechanically, instead of having a human open every page in a browser to eyeball it, is what makes it possible to check a large number of pages across a large number of sites against a consistent standard. Because status codes are a shared, unambiguous vocabulary, it becomes possible to verify “did this update break anything?” after every single change — without depending on human attention, and while leaving a clear trail of what was checked.

Summary

Once you have both the broad category behind the three-digit number and the habit of reading it as “how did this change compared to right before” rather than in isolation, monitoring design gets noticeably more accurate.