Your server returns a 200 OK. Everything looks fine from the outside. But the page is blank. Or the API response is missing half its data. Or your app is serving a generic error page with a friendly message and a perfectly healthy status code.

HTTP status codes are the first line of defense in uptime monitoring, but they only tell you that the server responded -- not that it responded correctly. A web server can happily return 200 while serving a maintenance page, a login redirect, a stack trace, or an empty body. If all you check is the status code, these failures slip through silently.

That is where keyword monitoring comes in. It reads the actual response body and checks for a specific string, catching the failures that status codes miss.

How keyword monitoring works in CronAlert

When CronAlert runs a check on your monitor, it follows a two-step process:

  1. Status code check. CronAlert sends an HTTP request to your URL and compares the response status code against your expected status code (usually 200). If the status code does not match, the check fails immediately and you get an alert. Keyword monitoring does not run.
  2. Keyword check. If the status code matches, CronAlert reads the response body and searches for your keyword string. Depending on your match type, it either verifies the keyword is present or verifies it is absent.

This ordering is intentional. There is no point scanning the body of a 500 Internal Server Error for a keyword -- the status code already tells you something is wrong. Keyword monitoring adds a second layer of verification on top of status code checks, not a replacement for them.

Two match types: contains and not_contains

CronAlert supports two keyword match modes that cover different monitoring scenarios.

Contains: verify expected content is present

The contains match type alerts you when your keyword is not found in the response body. Use this when you want to confirm that a specific piece of content is always present.

If the keyword is missing, the check fails with the error: 

Keyword 'your keyword here' not found in response

This is the mode you will use most often. It answers the question: "Is my page still showing what it should be showing?"

Not contains: verify unwanted content is absent

The not_contains match type alerts you when your keyword is found in the response body. Use this when you want to catch the appearance of something that should not be there.

If the keyword is detected, the check fails with the error: 

Keyword 'your keyword here' found in response (expected not to be)

This mode is defensive. It answers the question: "Is my page free from error messages, maintenance notices, or other content that signals a problem?"

Practical use cases

The theory is straightforward, but the real value shows up in practice. Here are the patterns that developers use most.

Catch blank pages and broken renders

Set your keyword to your company name or a string that always appears on the page, like a navigation element or a footer copyright notice. If a deployment breaks the frontend and your server starts returning an empty body or a minimal error page, the keyword check catches it.

  • URL: https://yoursite.com
  • Match type: contains
  • Keyword: Your Company Name

A 200 with a blank page? Caught. A 200 with a CDN error page? Caught. A 200 with a login redirect that stripped all your content? Caught.

Validate API responses

JSON APIs can return 200 with malformed or incomplete data. If your API should always return a specific key in its response, use keyword monitoring to verify it is there.

  • URL: https://api.yoursite.com/health
  • Match type: contains
  • Keyword: "status":"ok"

This works well for health check endpoints that return a JSON body. If the response structure changes or the status value flips to something else, the check fails.

Detect silent errors and exception messages

Some frameworks catch exceptions and render a friendly error page with a 200 status code. You can monitor for the appearance of common error strings.

  • URL: https://yoursite.com/dashboard
  • Match type: not_contains
  • Keyword: Internal Server Error

Other good candidates for not_contains monitoring: Exception, stack trace, maintenance mode, temporarily unavailable, or any error string your framework tends to leak into the response body.

Verify specific content is still listed

Running an e-commerce site and want to make sure a critical product is still listed? Monitoring a directory page and want to confirm your listing has not been removed? Use contains with the specific text you expect to find.

  • URL: https://marketplace.example.com/your-product
  • Match type: contains
  • Keyword: Add to Cart

If the product page gets delisted, replaced, or broken, the keyword disappears and you get an alert.

Setting it up

Keyword monitoring is configured per-monitor in the CronAlert dashboard:

  1. Go to your dashboard and create a new monitor or edit an existing one.
  2. Under the monitor settings, enable the keyword check option.
  3. Enter your keyword string (up to 500 characters).
  4. Choose your match type: contains or not_contains.
  5. Save the monitor. The keyword check runs on every subsequent check alongside the status code verification.

That is it. No additional configuration, no separate service. Keyword monitoring is built into the same check pipeline that already handles your HTTP status code verification.

Tips for getting the most out of keyword monitoring

Be specific with your keywords

Vague keywords lead to false positives. Monitoring for the word "error" with not_contains could trigger on a page that legitimately discusses error handling. Instead, monitor for a more specific string like 500 Internal Server Error or the exact error message your framework produces. The more specific the keyword, the fewer false alerts you will deal with.

Use it alongside status code checks, not instead of them

Keyword monitoring is designed as a second layer. CronAlert enforces this by only running the keyword check when the status code matches. Do not rely on keyword monitoring alone to catch outages -- a timeout or a 503 will be caught by the status code check before the keyword check ever runs. The two work together.

Monitor JSON APIs for expected keys

If your API returns JSON, you can monitor for a specific key-value pair. For a health endpoint that returns {"status":"ok","version":"2.4.1"}, searching for "status":"ok" verifies both that the endpoint is returning valid JSON and that the status field has the expected value. Keep in mind that this is a plain string match, not a JSON parser -- whitespace and key ordering matter.

Keep an eye on keyword length

Keywords can be up to 500 characters, which is generous for most use cases. But longer keywords are more brittle -- a minor copy change could break the match. For most monitors, a short, stable string (10-50 characters) that is unlikely to change is the sweet spot.

Frequently asked questions

Do I need a paid plan to use keyword monitoring?

Yes. Keyword monitoring is available on the Pro plan ($5/month) and above. The free plan includes HTTP status code monitoring, alerts via email, Slack, Discord, and webhooks, and up to 25 monitors -- but keyword monitoring requires Pro or higher.

Is keyword matching case sensitive?

Yes. If you search for Error, it will not match error or ERROR. Make sure your keyword matches the exact casing that appears in the response body. If you are unsure of the casing, check the raw response first by viewing a recent check result in the dashboard.

What is the maximum keyword length?

500 characters. This is enough for multi-word phrases, JSON key-value pairs, or specific error messages. In practice, shorter keywords (under 100 characters) are more reliable since they are less likely to break when content around them changes.

Beyond status codes

Status code monitoring tells you the server is responding. Keyword monitoring tells you it is responding with the right content. Together, they cover the two most common categories of silent failures: servers that go down and servers that stay up but serve the wrong thing.

If you have ever had a deployment break a page without triggering any alerts, keyword monitoring is the fix. Set it up on your most critical endpoints, pick a stable keyword that should always be present, and stop relying on status codes alone.