Monitor Configuration
Fine-tune your monitors with custom HTTP methods, headers, keyword checks, expected status codes, timeouts, and AI-assisted setup.
Monitor Configuration
Beyond the basic setup, Seenty offers detailed configuration options for HTTP monitors. These let you monitor authenticated endpoints, validate response content, and handle non-standard server behaviors.
HTTP method
By default, HTTP monitors use the GET method. You can change this to any standard HTTP method:
| Method | Typical use case |
|---|---|
| GET | Standard health check endpoints, web pages |
| HEAD | Lightweight checks that only need the response headers (no body) |
| POST | Endpoints that require a payload, such as login or webhook receivers |
| PUT | Update endpoints used for health verification |
| PATCH | Partial update endpoints |
| DELETE | Cleanup or teardown verification endpoints |
HEAD requests are useful when you want to minimize bandwidth -- the server returns headers but no response body, which is faster and lighter on your endpoint.
Custom request headers
Add any number of custom headers to your check request. Common use cases:
- Authorization --
Bearer <token>for authenticated endpoints - Accept --
application/jsonto request JSON responses - X-Custom-Header -- Any application-specific header your endpoint requires
- Content-Type -- Set when sending a request body (e.g.,
application/json)
Headers are sent with every check request. If your endpoint requires authentication, use a long-lived API key or service token rather than a short-lived user token.
Store sensitive values like API keys carefully. Header values are encrypted at rest but are visible to organization members who can edit the monitor.
Custom request body
For POST, PUT, and PATCH requests, you can define a request body. This is useful for:
- Health check endpoints that require a specific payload
- APIs that use POST for read operations
- Endpoints that validate request structure as part of their health check
Enter the body as raw text. Set the Content-Type header to match your payload format (e.g., application/json for JSON bodies).
Example: Monitoring a GraphQL endpoint with an introspection query:
{
"query": "{ __typename }"
}Keyword checking
Keyword checks let you validate the content of the response, not just the status code. A server might return a 200 status code but serve an error page -- keyword checking catches this.
Two modes are available:
- Contains -- The check passes only if the response body includes the specified string
- Does not contain -- The check passes only if the response body does not include the specified string
Examples:
| Mode | Keyword | Use case |
|---|---|---|
| Contains | "status":"healthy" | Verify a JSON health endpoint returns the expected status |
| Contains | Welcome | Verify a login page is rendering correctly |
| Does not contain | 503 Service Unavailable | Catch error pages served with a 200 status code |
| Does not contain | maintenance | Detect maintenance mode pages |
Keyword matching is case-sensitive and searches the full response body.
Expected status codes
By default, Seenty considers any response in the 200-299 range as successful. You can customize this to match your endpoint's behavior:
- Specific code:
200-- Only accept exactly 200 - Range:
200-299-- Accept any 2xx response (default) - Multiple codes:
200, 301-- Accept either 200 or 301 - Redirect codes:
301, 302-- Useful when monitoring URLs that should always redirect
This is particularly useful for monitoring redirect endpoints, APIs that return 204 No Content, or services that use non-standard success codes.
Timeout
The timeout controls how long Seenty waits for a response before considering the check failed. The default is 30 seconds.
- Lower the timeout for fast endpoints where a slow response indicates a problem
- Increase the timeout for endpoints that legitimately take longer to respond (e.g., batch processing health checks)
If a check times out, it counts as a failure toward the alert threshold.
Follow redirects
By default, HTTP monitors follow redirects (3xx responses) to the final destination and evaluate the final response. You can disable this behavior when:
- You want to verify that a URL returns a specific redirect (combine with expected status code
301or302) - You want to monitor the redirect itself, not the destination
- The redirect chain is long and you want to catch redirect loops early
When disabled, the monitor evaluates the first response it receives, even if it is a redirect.
Alert modes
How alerts are delivered depends on your plan:
Available on all plans. When the monitor crosses the failure threshold, Seenty sends an alert directly to your configured notification channels (email, Slack, Discord, etc.).
- Alerts are sent immediately to all selected channels
- A recovery notification is sent when the monitor comes back online
- No incident is created -- there is no timeline or acknowledgment tracking
This mode is simple and effective for small teams or non-critical services where you do not need structured incident management.
Available on Pro plans and above. Instead of sending direct notifications, the monitor triggers an escalation policy when it fails.
- An incident is created with a full timeline
- Notifications follow the escalation steps (Step 0 immediately, Step 1 after a delay, etc.)
- The incident must be acknowledged and resolved, either manually or when the monitor recovers
- All actions are logged in the incident timeline
This mode is designed for production services where you need accountability, escalation, and a record of how the incident was handled. See Escalation Policies for details.
AI Monitor Assistant
The AI Monitor Assistant is available on Pro plans and above.
Instead of filling out every field manually, you can describe what you want to monitor in plain language and let the AI generate the configuration:
Example prompts:
- "Monitor api.example.com/health every minute and alert via Slack if it does not return 200"
- "Check that my-app.com responds in under 2 seconds with a body containing 'OK'"
- "Create a TCP monitor for my PostgreSQL database at db.example.com on port 5432"
The assistant generates the full monitor configuration -- type, URL, interval, headers, expected status, keyword check, and alert mode. Review the generated configuration, make any adjustments, and save.