Alert Rule Conditions: Status Code

Alert Rule Conditions: Status Code

A status code alert rule fires when the check receives an HTTP status code that matches (or doesn't match) your condition. This is the most direct way to detect when an endpoint is down.

How It Works

After every check, PulseAPI records the HTTP status code returned by the endpoint. The rule evaluates whether that code meets your condition.

Configuring a Status Code Rule

  1. In the alert rule form, set Condition Type to Status Code.
  2. Choose an Operator:
    • is equal to (==) — fires when the code matches exactly
    • is not equal to (!=) — fires when the code doesn't match (most common)
  3. Enter the Status Code value.

Common Patterns

Alert on Any Non-200 Response

The most common configuration — alert any time the endpoint doesn't return a success code:

  • Operator: is not equal to
  • Value: 200

Change 200 to match the expected status code configured on your monitor (e.g., 201, 204).

Alert on Server Errors Only (5xx)

PulseAPI evaluates exact codes, not ranges. To catch any 5xx error, you may create multiple rules or use a webhook to handle filtering on your end.

For the most critical server errors, start with:

  • 500 (Internal Server Error) — is equal to
  • 503 (Service Unavailable) — is equal to

Alert on a Specific Error Code

  • Operator: is equal to
  • Value: 404 — useful if a specific resource going 404 is a known failure mode

Status Code vs. Monitor Expected Status Code

These are two different settings:

  • Monitor expected status code (on the monitor config) — what PulseAPI records as a "successful" check in the check history. This affects uptime calculations.
  • Alert rule status code condition — separately evaluates the check result against the rule. A check can be "successful" (matched expected code) and still not trigger the rule, or vice versa.

Most of the time, align these: if your monitor's expected code is 200, your rule condition is typically "is not equal to 200."

Related Articles

Still have questions? Contact support.

    • Related Articles

    • Alert Rule Conditions: SSL Certificate Expiry

      An SSL expiry alert rule fires when your monitor's SSL certificate will expire within a specified number of days. This gives you advance warning before your certificate expires and causes real failures. How It Works PulseAPI reads the SSL certificate ...

    • Creating an Alert Rule

      This article walks you through creating an alert rule in PulseAPI. Alert rules define when PulseAPI creates an incident and sends notifications. Prerequisites: At least one notification channel must exist before you can assign it to a rule. See ...

    • Testing an Alert Rule

      The Test Rule feature lets you simulate your alert rule against current monitoring data to see what it would trigger — without creating a real incident or sending notifications. How to Test a Rule In the left sidebar, click Alerts, then Alert Rules. ...

    • Alert Rule Conditions: Response Time

      A response time alert rule fires when a check takes longer than a threshold you define. This article explains how to configure response time rules and recommends sensible starting thresholds. How It Works After every check, PulseAPI records the ...

    • Alert Rule Conditions: Uptime Percentage

      An uptime percentage alert rule fires when your monitor's uptime over a specified time window drops below a threshold. This is ideal for SLA-based alerting and reducing false positives from one-off check failures. How It Works Instead of evaluating ...