CronAlert has always checked HTTP status codes and keywords in response bodies. But status codes and string matching only cover part of the picture. What about pages that should change regularly but have gone stale? Or responses that need to match a complex pattern, not just a fixed string? Or content that should never change without you knowing about it?

Today we are shipping four new content checking modes that turn CronAlert into a full content monitoring tool alongside its uptime monitoring capabilities. All four are available on Pro plans and above.

The four new modes

Content checking is configured per-monitor, in the same place you previously set up keyword checks. The dropdown now offers six options:

Mode What it does Value field
Contains Alert if keyword is missing from response Keyword text
Not Contains Alert if keyword appears in response Keyword text
Regex Match Alert if regex pattern does not match response Regex pattern
Regex Not Match Alert if regex pattern matches response Regex pattern
Content Changed Alert when the response body changes None
Content Stale Alert when content has not changed in N days Number of days

The existing Contains and Not Contains modes work exactly as before. The four new modes are described below.

Regex matching

Sometimes a fixed keyword is not specific enough. You need to match a pattern: a version number, a date in a specific format, a JSON field with a numeric value, or an error code that varies.

Regex Match alerts you when the response body does not match your pattern. Use this to verify expected content is present in a flexible way.

Regex Not Match alerts you when the response body does match your pattern. Use this to catch error patterns, stack traces, or unwanted content that varies in its exact form.

Examples

Verify an API returns a version number in the expected format:

  • Mode: Regex Match
  • Pattern: "version":\s*"\d+\.\d+\.\d+"

Catch PHP errors that leak into production responses:

  • Mode: Regex Not Match
  • Pattern: (Fatal error|Warning|Notice):.+in .+\.php

Verify a page has a recent copyright year:

  • Mode: Regex Match
  • Pattern: © 202[5-9]

Patterns use standard JavaScript regex syntax. If your pattern is invalid, the check fails with a clear error message so you can fix it. The response body is capped at 1MB for regex matching to prevent memory issues.

Content change detection

Content change detection answers a different question than uptime monitoring. Instead of "is this page up?", it asks "has this page changed?"

When you set a monitor to Content Changed mode, CronAlert computes a SHA-256 hash of the response body on every check. The first check establishes a baseline. On every subsequent check, the new hash is compared against the stored hash. If they differ, the content has changed, and CronAlert creates an incident and sends your configured alerts.

How it works

  1. First check: CronAlert fetches the URL, hashes the response body, stores the hash, and marks the monitor as "up". This is your baseline.
  2. Subsequent checks (content unchanged): The hash matches the stored hash. Monitor stays "up". No alerts.
  3. Content changes: The hash differs. CronAlert updates the stored hash, creates an incident with the message "Content changed", and sends alerts. Once you acknowledge or the incident auto-resolves, the new content becomes the new baseline.

Use cases

  • Security monitoring: Alert when a page is modified unexpectedly. Catch defacements, unauthorized changes, or injected content.
  • Competitor tracking: Know when a competitor updates their pricing page, feature list, or documentation.
  • Compliance: Monitor legal pages (terms of service, privacy policy) for changes that need review.
  • Configuration drift: Watch a public config endpoint or manifest file for unexpected changes.

Content staleness alerts

Some pages should be updated regularly. A blog that has not been updated in months, a changelog with no recent entries, or a status page with stale data can signal neglect or an underlying problem.

Content Stale mode flips the content change model: instead of alerting when content changes, it alerts when content has not changed for too long.

How it works

  1. First check: CronAlert hashes the response, stores the hash, and records the current time as the "last changed" timestamp. Monitor is "up".
  2. Content changes: Hash differs, so CronAlert updates the hash and resets the "last changed" timestamp to now. Monitor stays "up" -- the content is fresh.
  3. Content stays the same: Hash matches. CronAlert checks how long since the "last changed" timestamp. If it exceeds your threshold (e.g. 3 days), the monitor goes "down" with the message "Content has not changed in 3 days".
  4. Recovery: When the content eventually changes, the monitor recovers automatically and you get a recovery alert.

Use cases

  • Blog freshness: Monitor your sitemap or blog index. Alert if no new posts in N days. We use this ourselves -- CronAlert monitors its own sitemap.xml and alerts the team if content goes stale for 3 days.
  • Documentation currency: Ensure docs stay up to date. If the docs site has not changed in 14 days, it might be falling behind the product.
  • Data feeds: Monitor an RSS feed, JSON data endpoint, or CSV export. If the data has not changed when it should be updating daily, something is broken upstream.
  • Changelog enforcement: Ensure your team is documenting releases. Monitor the changelog page and alert if it has not changed in a week.

Setting it up

Content monitoring is configured in the same place as keyword checks. When creating or editing a monitor:

  1. Find the Content Checking dropdown (previously called "Keyword Check").
  2. Select your mode: Regex Match, Regex Not Match, Content Changed, or Content Stale.
  3. For regex modes, enter your pattern. For Content Stale, enter the number of days. Content Changed requires no value.
  4. Save the monitor. The content check runs alongside the HTTP status code check on every interval.

You can also configure content monitoring via the REST API or MCP server using the keywordMatchType and keyword fields.

API example

Create a content staleness monitor via curl:

curl -X POST "https://cronalert.com/api/v1/monitors" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Blog Freshness",
    "url": "https://example.com/sitemap.xml",
    "keywordMatchType": "content_stale",
    "keyword": "7"
  }'

MCP example

Using Claude Code or any MCP client:

Create a content stale monitor for https://example.com/blog
that alerts if no changes in 3 days

The MCP server accepts the same keywordMatchType and keyword parameters as the REST API.

How content checks interact with other features

Content monitoring works with all existing CronAlert features:

  • Multi-region: For content change and staleness modes, CronAlert uses the hash from the first successful region response. All regions report the same content status.
  • Maintenance windows: Content checks still run during maintenance windows, but alerts are suppressed.
  • Incidents and status pages: Content changes and staleness alerts create incidents just like any other failure, appearing on your status pages.
  • All alert channels: Email, Slack, Discord, webhook, Teams, Telegram, PagerDuty, and push notifications all work with content alerts.

Frequently asked questions

What plan do I need for content monitoring?

All content checking modes (including the original keyword contains/not contains) require Pro ($5/month) or above. Free plan users see the options in the UI but they are disabled with an upgrade prompt.

How does content change detection work under the hood?

CronAlert computes a SHA-256 hash of the response body (capped at 1MB) on every check. The hash and a "last changed" timestamp are stored on the monitor record. Comparison is stateful -- it happens in the cron worker after the HTTP check completes, not in the probe workers.

Can I use regex patterns to monitor response bodies?

Yes. Patterns use standard JavaScript RegExp syntax. Invalid patterns fail the check with a descriptive error. The response body is capped at 1MB for regex matching.

What happens when I switch a monitor between content modes?

Switching to or from a content mode (Content Changed or Content Stale) resets the stored hash and timestamp. The next check establishes a new baseline. This prevents false alerts from stale hash data.

Does the content stale monitor check the full page or just headers?

It checks the full response body (up to 1MB). This means any change to the page content -- new posts, updated timestamps, modified text -- counts as a change and resets the staleness timer.

Combined uptime and content monitoring

Most monitoring tools make you choose: uptime monitoring or content monitoring, with separate products for each. CronAlert does both in one monitor. Every check verifies the status code first, then runs your content check. You get uptime alerts and content alerts from the same pipeline, the same alert channels, and the same dashboard.

Create a free account to get started, then upgrade to Pro to unlock content monitoring. If you are already on Pro or above, the new modes are available now in your monitor settings.