Content validation

Uptime tells you if an endpoint responds. Content validation tells you if it’s still correct.
Because “200 OK” can still mean: an error page, a login loop, missing keywords, or an API response that changed shape.

The most painful incidents are silent

Many failures don’t show up as downtime. They show up as a broken user flow — and you only hear about it when a client says “something feels off.”

• A deploy ships an error banner but still returns HTTP 200.
• A CMS edit removes the “Request demo” button.
• An API returns valid JSON… but the field your app needs is gone.
• A page is accidentally set to noindex, killing SEO quietly.

What we do

We perform HTTP checks and validate the response body, JSON shape/values, and basic page metadata — so you detect correctness regressions early.

Contains / does not contain

Keyword checks that catch error pages, missing UI text, and broken states.

JSON path checks

Validate that fields exist and equal the expected value.

Title & metadata

Catch accidental noindex, wrong title, or missing OpenGraph tags.

Reduce false greens

If your validation fails, the check fails — even if the server responds.

Examples (pseudo-config)

These snippets show the kind of rules you can set up. The idea is simple: define what “healthy” looks like for real users — not just for the load balancer.

1) Check a page contains a keyword

Confirm the critical UI text is present (for example: a login page still shows “Sign in”).

checks:
  - name: Login page keyword
    url: https://app.example.com/login
    expect:
      status: 200
      contains: "Sign in"

Example

2) Check a page does NOT contain a keyword

Fail the check when an error banner or maintenance message appears — even if the page returns 200.

checks:
  - name: No error banner
    url: https://app.example.com/
    expect:
      status: 200
      not_contains:
        - "Something went wrong"
        - "Internal Server Error"

Example

3) Check JSON path exists / equals a value

Validate API correctness: field exists and has the expected value. Great for /health endpoints.

checks:
  - name: API health
    url: https://api.example.com/health
    expect:
      status: 200
      json:
        - path: "$.status"
          equals: "ok"
        - path: "$.build.commit"
          exists: true

Example

4) Check title & metadata

Catch accidental noindex, wrong titles, or missing metadata after a CMS/template change.

checks:
  - name: Homepage metadata
    url: https://example.com/
    expect:
      status: 200
      title_contains: "Example"
      meta:
        - name: "robots"
          not_contains: "noindex"

Example

Who it’s for

MSPs & agencies

Prove what broke, when it broke, and reduce “it seems down?” client messages.

SaaS teams

Catch regressions right after deploys — before support tickets spike.

Ecommerce

Validate that key conversion paths still work (checkout text, inventory flags, error states).

Prevent silent failures

Add your first check in minutes: start with uptime, then layer in content validation so “200 OK” actually means “working.”

Back to solutions →