How do I verify a specific text (e.g. "OK") in the response content?

Short answer

In a Health Checks profile of the HTTP or HTTPS type, Basic (string match) (default) is left in the Content Check Mode field and the searched text (e.g. OK) is written in the Expected Content Query field; if the text does not occur in the response body, the check fails. This search is case-sensitive and is not a regular expression (regex). If a case-insensitive, pattern-based or JSON field-based check is required, the JSONata Expression mode is used; the same settings are written in WEB-CLI with --contentCheckMode and --contentQuery.

Problem: The Server Responds but the Application Is Unhealthy

Even if an application crashes, the web server can return an error page with code 200. A check that looks only at the status code cannot catch this situation; the server appears healthy and continues to receive traffic. A text showing that the application is actually running (e.g. OK, healthy) must be searched for in the body of the health page.

Solution: 3 Methods

Method 1 and Method 2 cannot be used together in the same profile; one of them is selected in the Content Check Mode field. Method 3 is the WEB-CLI counterpart of Method 1.

Your situation	Suitable method
The health page returns a fixed text	Method 1: Basic (string match)
A case-insensitive or pattern-based search, or a JSON field check, is required	Method 2: JSONata Expression
I create or update the profile from WEB-CLI	Method 3: WEB-CLI

Method 1: Basic (string match) Recommended

• How it works If the searched text occurs in the response body, the content check is successful; the leading and trailing spaces of the text are trimmed. The status code must also be in the Expected Status Codes list.
• Where it is openedLoad Balancer → Profiles → Health Checks → HTTP/HTTPS profile → Content Check Mode → Expected Content Query
• Requirement The health page returning a fixed text; a Backend Service to which the profile will be assigned
• vService type All (in Network vService, with ANY - L3 or while Port Range is on, the health status is not reflected in distribution)

Step-by-Step Configuration

1

Adım 1 Open the Health Checks screen

The Configuration Menu is opened with the TR7 logo at the bottom left; the Load Balancer → Profiles → Health Checks path is followed.

2

Adım 2 Open the form

For a new profile, Add is clicked; for an existing HTTP/HTTPS profile, the profile is selected and Edit is clicked (How to add?).

3

Adım 3 Enter the name, type and health address

In a new profile, Name is entered and Check Type HTTP (default) or HTTPS is selected; the health address is written in the Path + Query field (e.g. /health). In an existing profile, this step is skipped.

4

Adım 4 Check the status code

In the Expected Status Codes list, it is checked that the code returned by the health page (default 200: OK) is selected; the status code and the content must be met together.

5

Adım 5 Write the searched text

Basic (string match) (default) is left in the Content Check Mode field; the searched text is written in the Expected Content Query field (e.g. OK).

6

Adım 6 Save the profile

The Add (Edit when editing) button at the bottom of the form is clicked. If the profile is already assigned, the change is applied to all the Backend Services that use the profile.

7

Adım 7 Open the Backend Service form

For a new profile, the Load Balancer → Backend Services path is followed; the Backend Service is right-clicked and Edit is selected.

8

Adım 8 Select the profile

The profile is selected in the Health Check field.

9

Adım 9 Save

The Edit button at the bottom of the form is clicked. In a cluster, the change is transferred to the peer device automatically by default; if Manual Sync Mode is on, it is sent with Synchronize.

Verification

1Health statusBackend Services list

The indicator in the Health column of the Backend Services list is checked (Health status indicator).

ExpectedOK (green)

2When the text is not foundHealth Checks tab

When the text on the health page is changed temporarily, a content error appears in the Health Checks tab in the preview of the Backend Service; after Required failures consecutive failures, the status becomes Error.

ExpectedHTTP / HTTP(s) content check failed

Method 2: JSONata expression

• How it works The expression evaluates the status code (status), the response headers (headers), the parsed body (body) and the raw body (bodyRaw); if the result is true (truthy), the content check is successful. Case-insensitive search and regular expressions can be used.
• Where it is opened HTTP/HTTPS profile → Content Check Mode → JSONata Expression → JSONata Query
• Requirement The code returned by the health page being in the Expected Status Codes list
• vService type All

Step-by-Step Configuration

1

Adım 1 Open the profile form

On the Load Balancer → Profiles → Health Checks screen, the HTTP/HTTPS profile is selected and Edit is clicked (Add for a new profile).

2

Adım 2 Select the mode

JSONata Expression is selected in the Content Check Mode field; the JSONata Query field appears in place of the Expected Content Query field.

3

Adım 3 Write the expression

The expression is written in the JSONata Query field; for example, $contains(bodyRaw, /ok/i) for a case-insensitive search, body.status = "UP" for a JSON body. In the field's editor, the expression can be tried on a sample response.

4

Adım 4 Save the profile

The Edit (Add in a new profile) button is clicked; the new profile is selected in the Health Check field of the Backend Service as in Method 1.

Verification

1Health statusBackend Services list

The indicator in the Health column of the Backend Services list is checked; if the expression is not met, a JSONata error appears in the Health Check card of the preview (Health status indicator).

ExpectedOK (green)

Method 3: WEB-CLI

• How it works The settings in Method 1 are written with the --contentCheckMode basic and --contentQuery fields.
• Where it is opened WEB-CLI → lb hc add / lb hc update (lb hc · The HTTP and HTTPS Fields)
• Requirement WEB-CLI access; the ID of the Backend Service to assign the profile
• vService type All

Step-by-Step Configuration

1

Adım 1 Create the profile

checkType and name are required and are written in this order; if --expectedStatusCodes is not written, 200 is used:

lb hc add checkType http name web-icerik --uri /health --contentCheckMode basic --contentQuery "OK"

If only the searched text is to be changed in an existing HTTP/HTTPS profile whose Content Check Mode field is Basic (string match):

lb hc update id <profile-id> --contentQuery "OK"

2

Adım 2 Assign the profile to the Backend Service

The profile ID is taken from the lb hc list output, and the Backend Service ID from the lb backend list output:

lb backend update id <backend-id> --hc <profile-id>

Verification

1RecordWEB-CLI

The profile record is displayed.

Commandlb hc show <profile-id>

ExpectedcontentCheckMode basic, contentQuery OK

Common Mistakes

• Writing a regex. In Basic mode, the text is searched as is; for a pattern, JSONata Expression is used.
• Overlooking the case difference. A search for ok does not match the OK text.
• Searching JSON as text. A search for "status":"up" does not match a "status": "up" (with a space) body; for JSON, JSONata Expression is preferred.
• Forgetting the status code. Even if the content is correct, the check fails if the code is not in the Expected Status Codes list.

How it is done in the documentation

• Health Checks · Content Check Mode
• Health Checks · Expected Content Query
• Health Checks · JSONata Query
• WEB-CLI · lb hc · The HTTP and HTTPS Fields

Related questions

• Can I validate a JSON response field by field in a health check (Content Check Mode: JSONata Expression)?
• How do I expect a specific status code (e.g. 200, 302) in an HTTP health check?
• What kind of /health endpoint should I design in my application for health checks?