StackPulse runs checks on a schedule to understand whether your apps and services are responding as expected.
Each check attempts to reach the endpoint you configured. The result is evaluated against the check settings and becomes part of the current health state for that app or service.
Check execution
Checks run at their configured interval.
Each run:
- Sends a request to the configured endpoint.
- Waits for a response.
- Evaluates the expected result, such as status code or content rules.
- Records the outcome for incident and alert handling.
Timeouts, connection errors, and failed assertions are handled as failed check runs.
Success vs failure
A check succeeds when the endpoint responds as expected.
A check fails when:
- The request cannot be completed.
- The endpoint returns the wrong status code.
- A configured assertion does not pass.
- The request times out.
Incident creation
Failures can open incidents. An incident represents an ongoing issue, not just one failed run.
If a check keeps failing while an incident is open, StackPulse updates the existing incident instead of creating a new one for every run. This keeps the incident list focused on active problems.
Alerting
Alerts are sent when incidents are opened. If resolution notifications are enabled, StackPulse can also send an alert when an incident recovers.
Delivery status is tracked so you can see whether StackPulse attempted to send the alert and whether the provider accepted it.
Recovery
When checks start passing again, StackPulse resolves the related incident.
If resolution alerts are enabled, StackPulse sends a recovery notification so your team knows the issue has cleared.
Important notes
- Checks are best-effort signals, not real-time guarantees.
- Network issues can cause transient failures.
- Use intervals and thresholds that match the importance and expected behavior of the service.