HTTPS
Website and API monitoring
A page or an endpoint, fetched from three continents.
Try it now
One check, from one place, right now, and nothing is saved. A monitor checks from every location we run and confirms a failure from a second continent before anybody is woken, which a single look cannot show you.
What it is for
The check everybody starts with, and the one most products stop at. We request the URL, follow or refuse redirects as you say, and read the status code.
A status code on its own is a weak promise. A site can return 200 while serving an error page, a login screen, a cached copy from last Tuesday, or an empty shell that failed to render. So the check can also require a phrase to be present, a redirect to land somewhere specific, a JSON field to hold a particular value, and a response to arrive inside a time you set. Those are the failures a status code cannot see.
Like every check here, it runs from Amsterdam, New York and Singapore, and a failure is confirmed from a second continent before anybody is woken. How that works.
What you can set
Everything below is on the form when you add one, on every plan.
- Method
- GET, HEAD, POST, PUT, PATCH or DELETE. HEAD is the polite default for a page you only need to know exists.
- Expected status
- Which codes count as healthy. A 401 is correct for an endpoint that should refuse you, and saying so stops us reporting your authentication working as an outage.
- Keyword
- A phrase that has to be there, or has to be absent. The cheapest way to catch a 200 that is really an error page.
- JSON assertions
- A path and the value it should hold, for an API that answers 200 with a body saying otherwise.
- Redirects
- Follow the chain, or treat a redirect as the answer. With an expected location, this catches a site quietly redirected somewhere it should not be.
- Slow is a failure
- A response time above which the check counts as degraded rather than up, and how many in a row before we say so.
- Authentication
- Basic or Bearer. Stored encrypted, decrypted by the control plane, and handed to the probe with the assignment rather than giving a rented machine the key to everything.
- Headers and body
- Anything the request needs. One header per line, and a body for the methods that take one.
- Timeout
- How long to wait before calling it a failure.
- Confirmations
- How many other continents must agree before anybody is woken. Zero is available and is rarely what you want.
Questions
What does a 502 or a 503 mean, and will you alert on it?
A 502 is the server in front telling you the one behind it gave an answer it could not use, and a 503 is a server saying it is not taking requests, which is what most frameworks return while they restart. Both fail the check by default, because the default expects 2xx and 3xx. If a code is correct for that endpoint, put it in the expected status list and it stops being an outage.
Do you verify the SSL/TLS certificate chain?
Yes. The check connects the way a browser does, against the public trust store, so a missing intermediate, a self-signed certificate, a hostname mismatch or an expired one fails the check with a TLS error rather than a status code. What it does not do is count the days left, which is the SSL/TLS certificate monitor's job. Verification can be turned off per monitor for an internal host you know about.
Can I monitor an API endpoint rather than a page?
That is what the request options are for, and it is why there is no separate API monitor type to drift from this one. Choose POST, PUT, PATCH or DELETE, add headers and a body, authenticate with basic or bearer credentials, accept whichever status codes are correct, and assert on a path in the JSON that comes back.
What is the difference between a timeout and a slow response?
A timeout is a check that never got an answer inside the seconds you allowed, and it is reported as a failure with no status code, apart from a connection that was refused outright. Slow is an answer that arrived and took too long: set a response time above which the check counts as degraded, and how many in a row before anybody hears about it.
Do you follow redirects?
Not unless you say so, which surprises people often enough to be worth explaining. A site that starts answering 302 to a parking page is broken, and a checker that quietly follows it and finds a 200 would report that as healthy. Turn following on when the redirect is the point, and name the location you expect to end at.
Does the check run JavaScript or render the page?
No, and we say so rather than implying otherwise. It fetches the document the server sends and reads that, so a keyword check has to match something in the HTML rather than something a framework paints afterwards. For a page rendered in the browser, assert on the status code, the response time and a phrase that is genuinely in the response.
Is the response time what my visitors experience?
It is the time our probe waited, from request to response, on a connection with no cold cache and no browser in front of it. That makes it an excellent tripwire for a server getting slower and a poor model of one person on a phone. Real user monitoring and Core Web Vitals answer the other question and this check does not pretend to.