Blog/
HTTP vs keyword vs TCP monitoring
Which uptime check type to use: HTTP status, body keyword, or raw TCP port.
Not every outage looks the same. Picking the right check type saves false alarms and catches real failures.
HTTP / HTTPS
ReturnPod requests the URL. A 2xx or 3xx response counts as up. This is the default for websites and most APIs.
Use when: you care that the endpoint responds successfully.
Misses: a page that returns 200 with an error message in the HTML, or a JSON {"ok":false} with status 200.
Keyword check
Same as HTTP, but the response body must contain a string you set (for example "status":"ok" or Add to cart).
Use when: the server can return 200 while the app is logically broken.
Watch out: pick a stable string. Marketing copy that changes weekly will false-alarm you.
TCP check
ReturnPod tries to open a TCP connection to host:port (for example db.example.com:5432 or example.com:443).
Use when: you care that a port accepts connections, not that an HTTP body looks right.
Do not expose private database ports to the public internet just to monitor them. Prefer an HTTP health endpoint on a private network, or a heartbeat from inside the network.
Heartbeats (separate type)
Heartbeats are not outbound checks. Your job pings ReturnPod. If the ping stops, you get alerted. That is for cron and workers. See heartbeat monitoring.
Quick picker
| Situation | Check | |-----------|--------| | Marketing site or app URL | HTTP | | API that returns 200 on failure | Keyword | | Mail or game server port | TCP | | Nightly cron / worker | Heartbeat |
ReturnPod free includes HTTP, keyword, and TCP. Heartbeats are on Pro.