Skip to main content
The Errors sub-tab shows which requests failed, how often, and on which routes, so you can tell a real problem from background noise. It is available on every plan. Same data through the API: Application errors.

5xx: your app has a problem

A status starting with 5 (500, 502, 503, 504) means the server failed to answer. Visitors see these as broken pages, so they are always shown. Common causes: an exception in your code, a database that does not answer, an app that is restarting or ran out of memory, or a request that took too long. Pair this tab with the application logs to find the cause.

4xx: optional

A status starting with 4 (400, 401, 403, 404, 429) means the request itself was refused or pointed at something that does not exist. These are hidden by default; turn on Include 4xx to see them.
4xx is noisy. Bots and scanners constantly probe addresses like /wp-login.php or /.env, which produces a stream of 404 that says nothing about your site’s health. A high 4xx count is normal on any public site. Look at it only when you are chasing something specific, such as a broken link on your own pages or a 401 your login should not return.

What the tab shows

  • Totals by class: how many 5xx (and 4xx, if included) in the period.
  • Errors over time: a chart, so you can see whether the errors started with a deploy or at a given hour.
  • Routes with most errors: for each route, the error count and the error rate. Use both: a route with 3 errors out of 3 requests (100%) is a different problem from one with 300 out of 100,000 (0.3%).
  • Status distribution: how the errors split between 500, 502, 504, 404 and so on. Each class points to a different cause.

Investigating

  1. Look for the moment the line rises and compare it with your deploys.
  2. Click the worst route to filter everything by it.
  3. On Pro and above, open Requests to see the exact failing requests and note a request ID.
  4. Read the application logs for that time.
Next: Performance.
Last modified on November 3, 2026