TCP checks
Use TCP for public services that expose a TCP listener. A successful connection proves the port accepted a connection, not that application authentication, queries or message processing succeeded.
- Create a TCP check.
- Enter a bare public hostname, such as
example.com, and a port. - Choose a plan-supported interval and save.
- Inspect the first connection result and its connection duration.
- Add probe regions and adjust quorum if you need multi-region evaluation.
| Option | Constraint |
|---|---|
| Name | Required |
| Hostname | Bare ASCII public hostname, without a scheme or path |
| Port | Integer from 1 to 65535; required |
| Interval | Positive seconds at or above the account’s minimum |
| Probe locations | Available Pingstack regions within the plan allowance |
| Healthy/failing counts | Positive counts; healthy can be blank for all locations |
| Notification groups | Existing account groups |
TCP checks use interval scheduling, not cron. Connection refusal, timeout and network failures can produce failed results. Infrastructure-suspect failures are recorded without changing target health.
Choose website monitoring when an HTTP response code is the meaningful health signal. Use heartbeats if the service is private or only the worker itself can confirm useful work.