Technical
HTTP status
HTTP status is the three-digit number in a response's first line that tells the client how the request ended. The first digit gives the class: 2 success, 3 redirect, 4 client error, 5 server error.
How it is measured
`curl -I https://example.com/` prints the status line. In bulk, read the status field from access logs and group by code and path. Reports usually show each code as a share of all responses.
Read the code with its headers. A 301 needs `Location`, a 401 needs `WWW-Authenticate`, and a 429 usually carries `Retry-After`. A code without its header is often a misconfiguration.
Worked example
A Hugo site's weekly log holds 118,000 responses: 101,400 are 200, 9,800 are 304, 4,900 are 301 from http to https, 1,500 are 404, 400 are 403 from a blocked scraper, and none are 5xx. The high 301 share suggests internal links still use http.
The next week shows 340 5xx responses inside a single 15-minute window, which lines up with a database restart.
How it differs
HTTP status is the whole code family. HTTP 404 is one member, saying not found. The class tells you whose side to look at first, and the specific code tells you what to fix.
Common errors
Returning 200 with an error message in the body. Treating every 4xx as the visitor's fault when 429 and 403 may come from your own rules. Confusing 301 and 302. Reading 304 as a failure. Returning 500 for bad input. Retrying automatically on every 4xx.
In practice
Build a table of status share by class from last week's logs and compare it each week. Investigate any sudden shift in one class. Check that your error pages return the correct code.