Question 1

What does a 502 or a 503 mean, and will you alert on it?

Accepted Answer

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.

Question 2

Do you verify the SSL/TLS certificate chain?

Accepted Answer

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.

Question 3

Can I monitor an API endpoint rather than a page?

Accepted Answer

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.

Question 4

What is the difference between a timeout and a slow response?

Accepted Answer

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.

Question 5

Do you follow redirects?

Accepted Answer

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.

Question 6

Does the check run JavaScript or render the page?

Accepted Answer

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.

Question 7

Is the response time what my visitors experience?

Accepted Answer

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.

Question 8

Why not just curl it from a cron job?

Accepted Answer

For one URL from one machine, a cron job genuinely is most of this, and anybody who tells you otherwise is selling something. What it does not give you is somewhere to run that cannot itself die quietly: a check on a box that has lost its network reports nothing, which looks exactly like everything being fine. Nor does it tell a broken link between you and the site from the site being broken, which is what checking again from two other continents is for, and it still leaves you to build the part that wakes somebody up.

Question 9

How is this different from a browser based synthetic check?

Accepted Answer

A synthetic check drives a real browser, so it sees things we cannot: a page that renders blank because a script threw, a button that stopped working, a font that never loaded. This check makes the request and reads the answer, which means it cannot see any of that. What it gives you instead is a check cheap enough to run every thirty seconds from three continents, on every URL you have, rather than a handful of journeys a few times an hour. They answer different questions and plenty of people want both.

网站和API监控

立即尝试

它的用途

你可以设置什么

问题

502或503是什么意思，你会对此发出警报吗？

你会验证SSL/TLS证书链吗？

我可以监控API端点而不是页面吗？

超时和响应缓慢有什么区别？

你会跟随重定向吗？

检查会运行JavaScript或渲染页面吗？

响应时间是我的访客实际体验的吗？

为什么不直接用cron作业里的curl？

这与基于浏览器的合成检查有何不同？

其他检查