Quick answer
Why HTTP monitoring is blind to internal infrastructure failures, and how raw TCP sockets fix the gap.
Your Nginx is Up, Your Postgres is Down
A standard HTTP monitor hits your domain and gets a webpage. But what if that webpage is just a cached CDN response? Your frontend looks fine, but your backend database is completely locked up. You won't know until users try to log in and get slammed with 500 errors.
Dropping Down to Layer 4
To monitor backend infrastructure, you have to bypass HTTP overhead completely. This means establishing a direct raw TCP socket connection to a specific IP and Port—like 3306 for MySQL, 5432 for PostgreSQL, or 22 for SSH.
True Infrastructure Visibility
By executing these raw handshakes, you verify that the underlying machine and the specific service daemon are actually accepting connections. If the database socket refuses the connection, you get an alert instantly, long before the frontend cache expires and exposes the crash to your users.
Related PingStag guides
How to Monitor PostgreSQL Availability on Port 5432
Learn how TCP port monitoring can detect PostgreSQL availability problems even when your website still appears to be working.
How to Monitor MySQL Availability on Port 3306
A practical guide to MySQL TCP monitoring, what port 3306 can tell you, and why database monitoring should complement website uptime checks.
Cloudflare 403s vs Real Downtime: Decoding WAF Blocks
Your monitoring bot got blocked by a firewall, but the site is fine. How Layer-7 heuristics stop fake alerts.
How to Monitor Redis on Port 6379
Learn why Redis availability matters, how TCP port 6379 monitoring works, and where a cache availability check fits in a production monitoring strategy.
