# monitor.status-code-summary
Counts a batch of HTTP status codes by class, as RFC 9110 section 15 groups
them (1xx informational, 2xx successful, 3xx redirection, 4xx client error,
5xx server error), and gives two rates in basis points (10000 = 100%).
## Why 5xx and 4xx are separate
`errorRateBasisPoints` counts only 5xx: the server failed a request it should
have served, which is what an availability SLO measures (the Google SRE book's
request-based availability counts server errors). A 404 or 429 is usually the
client's doing, or the server working as designed, so it is reported apart as
`clientErrorRateBasisPoints` rather than burning the error budget. A sudden
rise in 4xx is still worth watching, which is why it is there at all.
## Rounding
Both rates are rounded half up (`math.round-div`): 2 in 3 is 6667, 1 in 32
(312.5) is 313. An empty list gives zeros rather than dividing by zero.
## Errors
- `status code must be 100 to 599, received 600`
- `status code must be a whole number` (a fractional value)
## Sources
- RFC 9110, HTTP Semantics, section 15 "Status Codes",
https://www.rfc-editor.org/rfc/rfc9110#section-15
- Google SRE book, "Embracing Risk" (request success rate as availability),
https://sre.google/sre-book/embracing-risk/