Monitoring assertions that catch wrong responses

Uptimia tests the status, headers, JSON fields, body text and response time you choose on every run, so a 200 with the wrong content still fails. The alert names the step, the rule that broke and the value that came back.

Start free trial → Compare five responses that returned 200
30-day free trial No credit card GDPR-ready

What a status check lets through

All five responses below answered HTTP 200, and a status-code check passed every one. Four of them are broken, and in each case one rule on the part that went wrong fails the check.

Customers see all four as outages. Sign-in never completes, the order list is empty, the stock page shows a maintenance notice, and search stalls before it answers. With one rule per endpoint, each of those runs fails the check. On an API monitor the incident records the rule and the value it got, so whoever picks it up starts at the field that changed.

Response parts you can assert on

Each rule reads one part of the response and compares it with one of the conditions listed below. Put a rule on every part your app depends on, so that when one breaks, the alert names it.

  1. Status codeConditionsis · is one of · is 2xx
    Status code · is · 200

    Catches the 500 from the app, the 502 from the proxy and the 401 after someone rotated a key.

  2. HeaderConditionsexists · equals · contains
    Header · x-request-id · exists

    Fails when a proxy serves an HTML error page with a 200 status, or when a cache or gateway strips a header your app relies on.

  3. JSON bodyConditionsexists · equals · contains · is one of
    JSON body · $.status · equals · paid

    Catches a field that went null, a changed status word or an empty list where orders belong. A rule can read any field a JSONPath expression reaches.

  4. Body textConditionscontains · does not contain
    Body text · does not contain · "exception"

    Catches a stack trace or an error banner inside an otherwise well-formed response. You can require a phrase to be present, or ban one from appearing anywhere in the body.

  5. Response timeConditionsunder (ms)
    Response time · under (ms) · 800

    A correct answer that arrives after the budget still fails the step. You set the budget in milliseconds, per step.

A step with no rules passes on any 2xx, the same as the status check in the figure above. Each step of a chain takes up to 15 rules. Explore API monitoring →

Where assertion results appear

Each rule shows pass or fail from the first test run through to the exported incident report.

Test runs while you write rules

Use Run test, or Run to step N, before you save. Each step shows its assertion checklist with pass or fail and the value received, plus the response body with extracted values highlighted and a timing tab.

Check log and run detail

Every run is listed as passed or failed at step N, with the error, the location and the duration. Open one for a card per step with its HTTP code, response size, assertion tally and timing split.

Incident page and report export

The incident carries the failing step, the rule and what came back, and the alert email lists the checkpoints that saw it. Export the report later and the failing-step detail is still there.

Get alerts that namethe rule that failed.

Website monitors include keyword rules, and every step of an API monitor takes JSON and header rules.

Start your free 30-day trial →
30 days free no credit card cancel anytime

Alerts that name the failing rule

When an assertion fails, the incident and every alert sent for it name the step, the rule and the value that came back.

The incident line names the rule

One line gives the step number, the method and path, the rule that broke and the value it got. It appears on the incident page, in the incident list, and in chat and SMS alerts.

Expected and received values in the email

One sentence covers the step, the request it sent, the server's answer and what the rule expected. Below it, the email lists every checkpoint that saw the failure, with its flag and error.

Failures confirmed from other locations first

Before anyone is paged, other locations repeat the failed run. You choose how many checks must agree; at 1, the first failed run alerts.

  • Every location that saw it. The alert email lists each checkpoint with its flag, name, error and status.
  • The failing step stays on record. A closed incident's report export still names the step and the rule.
  • Recovery goes to the same people. When every step passes again, everyone who was alerted gets the recovery notice on the same channels.
Explore API monitoring → Explore false positive prevention →
Recovered · every step passing again duration

Assertions by monitor type

Each monitor type takes its own kind of rule. Whichever you use, a broken rule fails the check and alerts you the same way an outage does.

  • Website monitors take required and banned keywords on the HTML of a page, and port checks take a send-and-expect string for services that speak their own TCP protocol.
  • API monitors take status, header, JSON, body-text and response-time rules on every step of a chain of up to 15 requests.
  • Transaction monitors verify a page in a real browser, including text drawn by JavaScript, an element's state and the URL a journey ends on.
Explore keyword monitoring → Explore transaction monitoring →

Common assertion mistakes

A rule that pins an id or a timestamp pages you as soon as that value moves. Loose matching causes the reverse problem, where a broken response passes the check. Each case below shows the brittle rule beside its fix.

Pinning an id that changes

Ids, timestamps, ETags and request ids change on every run. Assert that the field exists, or is one of a known set, and extract the value if a later step needs it.

Header equals fails on a charset

Equals compares the whole header value, case included. When the server appends a charset or a boundary, use contains.

A substring that matches too much

Body text is a substring test on the raw body, so a short word like ok matches inside broken. A JSON rule on the field compares the whole value.

Also included

Masked secret variables

Keep client secrets and API keys in a locked variable and reference it in any step. The value is masked in logs and response snippets, and any token requested with it is fetched fresh on each run.

NameValue
base_urlhttps://api.example.com
api_secret•••••••• (stored)
referenced as {{api_secret}}

Recovery notices

Once every step passes again, the recovery notice says how long the endpoint was failing.

Orders API is DOWN14:32
Orders API is UPAll 2 steps passing again

Maintenance windows

If a release changes responses on purpose, pause the checks for the deploy window and nobody gets paged.

00:00Window · 02:00⁠–⁠02:3024:00
Deploy window → no alerts

Optional steps

Mark a cleanup or best-effort step optional. Its failure is recorded and the rest of the chain keeps running.

DELETE /orders/{{order_id}}optional
✓ run still passes

Checks from chosen regions

Bind a monitor to a built-in location profile such as Europe, North America or Asia, so its rules run where your users are.

EuropeNorth AmericaAsia
Location profile · Asia

One dashboard for everything

Your assertion rules sit in the same account as your SSL, domain and server monitors and alert the same contacts.

shop.caldmont.comUPTIME api.caldmont.com/ordersAPI Checkout journeyTRANSACTION

Rule sets for common endpoints

Each example below pairs a failure with the monitor settings that catch it and what you see when it fails.

Example 1API monitor

Login returns 200 with an error body

Sign-in starts rate-limiting real users. The endpoint still answers HTTP 200 quickly, with "ok": false and no token. A status check marks that healthy, so the first report comes from a customer writing to support.

Monitor settings Check intervalEvery 1 minute Rules on the step3 Step timeout10 s
What you see and what happens →
What you see
The check log marks the run failed at step 1. Open the run and the step card shows HTTP 200, 1 of 3 assertions passed, and the response body with the failing value.
What happens
The run counts as an outage. Other locations repeat it first, then the incident opens with step 1, assertion 2, the operator (json equals) and the value it got: false.
Example 2API monitor

Login token reused in the orders call

Step 1 signs in with a client secret and pulls the access token out of the response. Step 2 calls the orders API with that token and checks that the first order has an id, which is the same sequence your app follows.

Monitor settings Check intervalEvery 5 minutes Steps2 Secret variableapi_secret · masked
What you see and what happens →
What you see
Run test shows both steps with every rule ticked, and the body of step 1 highlights the extracted token. The secret is masked in logs and alerts.
What happens
While both steps pass, nobody is paged. If the login breaks, step 1 fails and step 2 is marked not run. The incident names step 1, so you know the login broke and the orders API was never called.
Example 3API monitor

Search response over its 600 ms budget

The search endpoint returns all 38 results with every field correct, in 1,730 ms. A shopper typing into the search box sees nothing for well over a second.

Monitor settings Check intervalEvery 1 minute Rules on the step2 Step timeout10 s
What you see and what happens →
What you see
The run detail splits the step into DNS, connect, TLS, wait and receive, so you can see whether the time went to the network or to the server preparing its answer. The step breakdown shows average and p95 time per step, which lets you set the budget from measured numbers.
What happens
The first run over 600 ms fails the step. With outage confirmation above 1, other locations repeat the chain before anyone is paged, so a single slow route cannot open an incident.
Example 4Website monitor

Product page missing its cart button

The catalogue service behind the shop stops answering. The page still renders with HTTP 200 and a heading, but where the cart button belongs, a notice says the item is unavailable.

Monitor settings Check intervalEvery 1 minute Keyword rules3 Timeout (seconds)30
What you see and what happens →
What you see
The check log shows the failed check with its location and the keyword error. Click the row for the probe, the URL and the error text.
What happens
The failed check is confirmed from other locations by default, then you are alerted. Keyword rules read the HTML as the server sent it. Text that JavaScript adds later needs a transaction monitor, which loads the page in a real browser.

Put a rule on the fieldyour app depends on.

Run test shows each rule passing or failing before you save the monitor.

Start your free 30-day trial →
30 days free no credit card cancel anytime

How monitoring assertions work

An assertion is a rule a response must satisfy, such as required text, a status code, a header, a JSON field or a millisecond budget, and Uptimia checks it on every run. When a rule breaks, the failure is confirmed from other locations by default and the alert names what failed (for an API rule, the step, the rule and the value that came back); when the run passes again, a recovery notice follows.

01What is an assertion in website monitoring?+
A rule the response must satisfy beyond arriving, such as "the page contains Add to cart", "the JSON field status equals ok" or "the answer arrives under 600 ms". Assertions catch failures that still answer: error pages served with a 200, APIs returning the wrong data on time.
02What can I assert on an API response?+
The status code (is, is one of, is 2xx), the response time against a millisecond budget (under, and strict: exactly 600 ms fails a 600 ms budget), any response header (exists, equals, contains), any JSON field addressed with JSONPath (exists, equals, contains, is one of), and the raw body text (contains, does not contain). Each step of a chain carries its own rules, up to 15 per step. A step with no rules passes on any 2xx.
03Which monitors take assertions?+
Website (HTTP/HTTPS) uptime monitors take required and banned keywords, and port checks take a send-and-expect string for TCP services. API monitors take the full rule set above on every step. Transaction monitors verify in a real browser: the URL, the HTTP status, that an element exists, the text on the page or inside an element, and the state of a checkbox, radio button or dropdown.
04How do I pass a value from one step to the next?+
Add an extraction to the step that receives it. It reads one value by JSON path (a token at $.data.access_token), by response-header name (x-request-id), or by regex, where the first capture group wins, which suits HTML or any body that is not JSON. The value becomes a {{variable}} for every later step. If an extraction finds nothing, that step fails on the spot, so a later step never runs against a variable that was never set.
05Why does my assertion fail on a healthy API?+
Most often it pins a value that changes. $.data[0].id equals 8812 passes until the next order is placed; timestamps, ETags and request ids behave the same. Assert that the field exists or is one of a known set, and extract the moving value if a later step needs it. A cleanup DELETE that finds nothing answers 404 and fails a step with no rules: allow it with Status code is one of 204, 404, or mark the step optional.
06How exact are the comparisons?+
Header names match in any case; header values and body text are compared exactly as sent, case included. Equals wants the whole value, so content-type equals application/json misses application/json; charset=utf-8, where contains matches. Body text contains ok also matches broken and token, so address the field instead: JSON $.status equals ok compares the whole value. A rule value of 5 matches the JSON number 5, but the JSON string "01234" only matches 01234 exactly.
07Can I compare a JSON number against a threshold?+
Not with a JSON rule, since those test exists, equals, contains and is one of. Put the millisecond budget on the response-time rule, which every step can carry, and for application-side numbers have the endpoint publish a verdict field, such as "db": "ok", that you can assert equals.
08Which JSONPath syntax is supported?+
Root $, dot and bracket member access ($.data.status, $['user-id']), array indexes including negative ones ($.items[-1]), and a final .length(). Wildcards, filters, slices and recursive descent are refused when you save, so every saved path runs.
09Can I use variables inside an assertion?+
Yes. A {{name}} in the value of a JSON, header or body-text rule is resolved before the comparison, so a step can require that the id it reads back equals the {{order_id}} an earlier step created. Status codes and millisecond budgets are literal numbers.
10Can I assert on the SSL certificate's issuer or TLS version?+
No. The certificate has its own monitor: SSL monitoring watches expiry and validity for the whole chain and alerts before visitors see a browser warning. Pair it with your website and API monitors. Explore SSL monitoring →
11Are assertions a paid add-on?+
No. Keyword rules come with every website (HTTP/HTTPS) uptime monitor, and the full rule set comes with every API monitor. The free plan includes 1 website and 1 API monitor at 5-minute intervals, and the 30-day trial opens every monitor type, no credit card.

Assertions for API and website monitors

Add rules on content, JSON fields, headers and response time, and a response has to be correct to count as healthy.

Start free trial →
30-day free trial JSONPath and keyword rules Failing rule named in alerts No credit card
Rules run from the monitor's first check.