Service Monitors
Create HTTP, Ping, and TCP monitors to track the uptime and performance of your services from multiple global regions.
Service Monitors
Service monitors are the foundation of Seenty's uptime tracking. They periodically check your endpoints and alert you the moment something goes wrong. Seenty supports four monitor types, each suited to different use cases.
Monitor types
HTTP monitors send real web requests to your endpoints and validate the response.
- Methods supported: GET, HEAD, POST, PUT, PATCH, DELETE
- Expected status codes: 2xx by default (customizable to any range or specific code)
- Keyword checking: Assert that the response body contains -- or does not contain -- a specific string
- Custom headers: Add Authorization tokens, Accept headers, or any custom header your endpoint requires
- Custom body: Send a JSON or form payload for POST/PUT requests
- Follow redirects: Optionally follow 3xx redirects to the final destination
- SSL validation: Automatically validates the SSL certificate chain (see SSL Certificates)
HTTP monitors are the most common type and work for websites, APIs, health check endpoints, and any service accessible over HTTP.
Ping monitors send ICMP echo requests to verify that a host is reachable at the network level.
- Use case: Check whether a server or network device is online, independent of any specific service running on it
- What it checks: Network reachability and round-trip time
- No port required: Ping operates at the network layer, so you only need a hostname or IP address
Ping monitors are useful for infrastructure-level checks where you want to know if a machine is reachable, regardless of which services are running.
TCP monitors attempt to open a connection to a specific port on your host.
- Use case: Verify that a service is listening on the expected port (e.g., database on 5432, Redis on 6379, SMTP on 25)
- What it checks: Whether a TCP connection can be established within the configured timeout
- No HTTP required: Works with any TCP-based service, not just web servers
TCP monitors are ideal for databases, message queues, mail servers, and other services that do not speak HTTP.
Check intervals and limits
The frequency of checks and the number of monitors you can create depend on your plan:
| Hobby | Starter | Pro | Ultra | Enterprise | |
|---|---|---|---|---|---|
| Check interval | 5 min | 3 min | 1 min | 1 min | 1 min |
| Monitor limit | 5 | 20 | 50 | 200 | Unlimited |
Alert threshold
Seenty does not alert on a single failed check. Instead, it waits for consecutive failures before triggering an alert. This avoids false positives caused by transient network issues.
The default threshold is 2 consecutive failures. You can adjust this per monitor -- a higher threshold means fewer false alarms but slower detection, while a lower threshold means faster detection but more sensitivity to brief glitches.
For example, with a 1-minute interval and a threshold of 3, Seenty will wait approximately 3 minutes of continuous failure before alerting.
Creating a monitor
Choose monitor type
Navigate to Operations > Monitors and click New Monitor. Select the monitor type: HTTP/HTTPS, Ping, or TCP.
Configure the target
Enter the URL (for HTTP) or hostname/IP and port (for Ping/TCP). Give the monitor a descriptive name so you can identify it at a glance -- for example, "Production API Health Check" or "Database Primary (TCP 5432)".
Set check interval
Choose how often Seenty should run the check. The minimum interval depends on your plan (see the table above).
Select monitoring regions
Pick which regions should run the check. Checks run from all selected regions in parallel, so you can detect region-specific outages. See Multi-Region Monitoring for details.
Configure alerts
Choose how you want to be notified when the monitor fails:
- Direct Notification (Hobby/Starter): Select one or more notification channels. When the monitor crosses the failure threshold, Seenty sends an alert directly to those channels.
- Escalation Policy (Pro+): Assign an escalation policy that defines a multi-step alert chain. See Escalation Policies.
Save and verify
Click Create Monitor. Seenty will run the first check immediately, and you will see the initial status within seconds.
AI Monitor Assistant (Pro+) -- Instead of configuring everything manually, you can describe what you want to monitor in plain language. For example, type "Monitor my API at api.example.com every minute and alert via Slack if it returns anything other than 200" and Seenty will generate the full monitor configuration for you. You can review and adjust before saving.
Monitor dashboard
The monitors dashboard shows all your monitors with their current status, uptime percentage, and average response time. Each monitor has a detail view with:
- Uptime history -- A visual timeline showing when the monitor was up (green) or down (red) over the retention period for your plan
- Response time chart -- Latency over time, broken down by monitoring region
- Recent checks -- A log of individual check results with status codes, response times, and any errors
- Certificate info -- For HTTPS monitors, details about the SSL certificate (see SSL Certificates)
What happens when a monitor fails
When a monitor crosses the alert threshold (consecutive failures), the next step depends on how you configured alerts:
- Direct Notification (Hobby/Starter): Seenty sends an alert to all configured notification channels immediately. When the monitor recovers, a recovery notification is sent.
- Escalation Policy (Pro+): Seenty creates an incident and begins the escalation flow. See Incident Lifecycle for the full process.
In both cases, Seenty sends a recovery notification when the monitor comes back online.