Get in Touch About the HTTP Checker

What to Include in a Bug Report

Email [email protected] with enough detail to reproduce the problem.

For checker bugs

If the checker shows a status or a redirect chain that differs from what your browser or curl gets, explains a header wrongly, or flags a caching setup that is correct for your case, send:

• The URL you checked and the user agent you picked.
• What the report showed versus what you expected, ideally with the raw headers from curl -sD - -o /dev/null pasted in.
• Whether a CDN sits in front of the site, if you know; most differences come from the edge answering differently by region.

Headers not in the dictionary

About a hundred headers have an explanation. Anything else is listed as "not in the known list", which is honest but not helpful. If a header you see often is missing, a short note with the name, who sends it and a link to its documentation gets it added in the next update.

For everything else

Questions about how the timing is measured, corrections to the headers guide or the status code reference, or a note that something written here is out of date all go to the same address. Requests for uptime monitoring, alerts, accounts, checks from other regions or a higher bulk cap will get a friendly no; the about page explains the boundaries. How submitted URLs are handled is covered in the privacy policy.

There is no form on this page on purpose: a form needs spam protection, and spam protection means loading a third-party script on a site that otherwise loads none.

Replies usually go out within a few days. If your message includes a URL for debugging, it gets read and then deleted, not kept as data.