تمام مضامینگائیڈ1 منٹ کا مطالعہ

What an uptime check sees – and what it does not

یہ متن ابھی آپ کی زبان میں دستیاب نہیں، اس لیے انگریزی میں دکھایا جا رہا ہے۔

HTTP, TCP, ping and DNS answer different questions. Knowing what a check really measures helps you choose the right monitor.

A laptop showing charts of load times

“The site is up” can mean many things. Each type of check asks a different, well-defined question. Here is which.

HTTP: does the web server answer sensibly?

Uptime requests the address and looks at the status code. 200 to 399 counts as up, so redirects do too. 404, 500 or 503 count as down, as does a timeout or a failed connection.

What a check does not see is what sits behind a correct status code: a page that serves an empty error message with status 200 counts as up. So it is best to check an address that only returns 200 when everything really works, for example a dedicated status endpoint that also asks the database.

TCP: does the port accept connections?

For services without a web page, such as mail servers or databases. The check opens a connection to the host and port and closes it again. It does not tell you whether the service behind it works correctly.

Ping: is the machine alive?

Ping shows whether a host answers on the network. But a web server can have crashed while the machine still answers ping, and some networks block ping entirely. On its own, ping is not a good check for a website.

DNS: does the name resolve?

If the domain has expired or a record is wrong, every visit fails before the first request. A DNS check catches exactly that.

Combine instead of guessing

For an important application, several monitors pay off: HTTP for the page customers see, TCP for the database behind it. If only one goes down, you know straight away where to look.