Check response keywords and SSL expiry

By CodaSky LLC · Updated October 15, 2026

An HTTP status code can miss an application error page that returns 200. A Pro keyword condition adds a response body assertion. SSL/TLS certificate observations provide a separate view of certificate expiry and connection validation.

Require a response keyword

Send this JSON to POST https://api.codaurl.com/api/v1/monitors using your CodaURL user-session Bearer token. Replace the example URL and keyword with values from your own endpoint.

{
  "url": "https://my-service.com/health",
  "name": "Application readiness",
  "expected_status": [
    200
  ],
  "check_interval_seconds": 300,
  "keyword": "service-ready",
  "keyword_mode": "contains"
}

The expected HTTP status and keyword condition must both pass. Use a distinctive service marker so an unrelated page is unlikely to match. Matching is case-sensitive and tests an exact substring, rather than a regular expression.

• contains requires the keyword to be present.
• not_contains requires the keyword to be absent.
• A keyword can contain up to 256 UTF-8 bytes.

Read the keyword result

Keyword checks use GET directly and inspect at most 64 KiB of the decoded response body. They don't execute JavaScript or store the response body. Check server-rendered text or a small health response.

A failed body assertion reports DOWN, keyword_mismatch, and keyword_matched: false. A passing assertion reports keyword_matched: true. The value is null when no assertion is configured or evaluation couldn't run. The monitor uses the same UP/DOWN alert flow as other availability checks.

Use PATCH /api/v1/monitors/<id> with keyword: null to remove the body condition. Omitting the keyword preserves it. Without a keyword condition, checks use HEAD with GET fallback only for HTTP 405 or 501.

Inspect certificate expiry and TLS separately

Pro monitors expose a daily certificate observation in monitor.ssl. Read valid_to, days_remaining, status, and last_checked_at for certificate health. Read ssl.tls.status and ssl.tls.error_code for the independent validated TLS handshake.

Certificate observation and TLS validation are separate results. An observation failure doesn't establish that the certificate is expired. The SSL snapshot isn't refreshed on every HTTP check, and it can be absent before the first paid snapshot. Free responses provide ssl.entitlement: pro_required instead.

Choose the check for the failure you care about

Use expected status codes for HTTP availability, a keyword for a specific body condition, and SSL fields for certificate and TLS health. These signals complement each other; a matching body doesn't establish that a certificate will remain valid.

See authenticated API monitoring to combine a keyword with request headers, or use the OpenAPI reference for the complete fields.