API Health Check

Overview

24/7 Monitoring

Continuously monitor the availability of your APIs

Performance Metrics

Track response times and success rates

Early Warning

Detect problems before users are affected

Automatic Notifications

Receive instant notifications for quick intervention

API Health Check settings form - All configuration fields

What is API Health Check?

Basic Concept

API Health Check is a monitoring system that automatically sends test requests at specified intervals to an API endpoint or web service you specify.

When to Use?

Critical API Monitoring

Continuous monitoring of critical APIs such as payment and authentication

SLA Tracking

Tracking and reporting of service level agreements

Performance Monitoring

Monitoring API response times and trend analysis

Uptime Monitoring

Tracking service uptime

How Does It Work?

Configuration

URL to be checked, HTTP method, expectations, and scheduling are determined

Scheduling

Test requests are automatically sent at specified times (e.g., every 5 minutes)

Test Execution

HTTP request is sent and response is received

Validation

Expectations (assertions) are checked:

• Response time check
• HTTP status code check
• Response content check
• XPath/JSONPath checks

Result Recording

Test result is recorded (successful/failed)

Notification

If the test fails, configured notifications are triggered

Quick Start

Creating Your First Health Check

Access from Menu

Click Main Menu → Monitoring → API Health Check

Create New Check

Click the "Create New" button

Fill in Basic Information

• Name: A name for your check (e.g., "Payment API Check")
• Description: Optional description

Enter Request Information

• HTTP Method: GET, POST, etc.
• URL: API endpoint to be tested

Set Scheduling

Determine check frequency (e.g., Every 5 minutes)

Save

Click the "Save" button

Creating New Health Check

Step 1: Basic Information

Name - Required

Enter a unique name for the health check. This name:

• Must be unique within the project
• Cannot start with a space
• System automatically checks the availability of the name

Good Name Examples:

• Payment API Monitoring
• User Service Health Check
• Third-Party Integration Check
• Homepage Availability Check

Description - Optional

You can enter descriptive information about the health check:

• Maximum 1000 characters
• Used to explain the purpose and scope of the check
• Displayed on the list page

Example Descriptions:

• Created for 24/7 monitoring of critical payment API
• Customer portal homepage availability check
• Third-party service provider integration monitoring

Status - Default: Active

Determines the active/passive status of the health check:

• Active: Check runs, scheduled tests are sent
• Passive: Check is stopped, no tests are sent (historical data is preserved)

Step 2: Scheduling Settings

Determine how frequently the health check will run. Scheduling is done using Cron Expression.

Common Scheduling Examples

Description	Cron Expression	Use Case
Every 5 minutes	0 */5 * ? * *	For critical APIs (most common)
Every 15 minutes	0 */15 * ? * *	For normal APIs
Every hour	0 0 * ? * *	For Test/Development environments
Every day at 09:00	0 0 9 * ? *	For daily reporting
Every Monday at 09:00	0 0 9 ? * MON	For weekly checks

ipucu

Recommendations:

• Critical APIs: Every 5 minutes
• Normal APIs: Every 15-30 minutes
• Test/Development: Every hour
• Reporting purposes: Daily or weekly

Step 3: Request Settings

In this section, you configure the information of the endpoint to be tested.

Select From Collection - Recommended

You can use test scenarios you previously created in Test Console:

Click Button

Click the "Select From Collection" button

Select Collection

View your test collections in the opened dialog

Select Scenario

Select the test scenario you want

Auto-Fill

Test information automatically fills the form

bilgi

Advantages:

• You save time
• You use consistent test scenarios
• You can manage your test scenarios centrally

HTTP Method - Required

Select HTTP request method:

GET

Data reading (most commonly used)

POST

Data sending

PUT

Data updating

DELETE

Data deletion

PATCH

Partial update

HEAD

Header information only

URL - Required

Enter the full URL of the endpoint to be tested:

Examples:

• https://api.example.com/users
• https://api.example.com/payment/verify
• http://localhost:8080/health
• https://api.example.com/v1/products?category=electronics

uyarı

Notes:

• URL must be absolute
• HTTPS and HTTP are supported
• Query parameters can be added to URL or specified in a separate field

Parameters - Optional

Used to add query parameters to URL:

Example:

• Parameter Name: userId
• Parameter Value: 12345

Result URL: https://api.example.com/users?userId=12345

Headers - Optional

Used to add headers to HTTP request:

Common Uses:

• Authorization: Bearer token123 or Basic base64encoded
• Content-Type: application/json, application/xml
• X-API-Key: your-api-key
• Custom Headers: Custom headers

Example:

• Header Name: Authorization
• Header Value: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Body - For POST/PUT/PATCH

You can enter request body:

Supported Formats:

• Raw: JSON, XML, Text
• Form URL Encoded: Form data

JSON Example:

{
    "userId": 12345,
    "action": "verify",
    "timestamp": "2024-01-15T10:30:00Z"
}

XML Example:

<request>
    <userId>12345</userId>
    <action>verify</action>
</request>

Step 4: Validation Settings

Validation (Assertion) settings determine the checks required for the test result to be considered successful.

Timeout Check (Timeout Assertion)

When this option is activated, the specified timeout value is also used for validation:

• Request must be responded to within the specified time
• Otherwise test is considered failed

HTTP Status Code Check (Status Code Assertion)

To perform HTTP status code check:

Activate Toggle

Activate the "Result Status Code" toggle

Enter Status Code

Enter the expected status code in the "Expected Status Code" field

Default Value: 200 (OK)

Common Status Codes:

• 200: Successful
• 201: Created
• 204: No Content
• 400: Bad Request
• 401: Unauthorized
• 404: Not Found
• 500: Server Error

Example Scenario:

• Expected Status Code: 200
• Actual Status Code: 200 → ✅ Successful
• Actual Status Code: 500 → ❌ Failed

Response Body Check (Body Assertion)

Checks whether the response body contains specific content:

Activate Toggle

Activate the "Result Body" toggle

Enter Content

Enter the expected content in the "Expected Result Body" field

Use Cases:

• Response should contain specific text: "status": "success"
• Response should contain specific value: "active": true
• Response should not be empty

Example:

• Expected: "status": "ok"
• Actual: {"status": "ok", "data": {...}} → ✅ Successful
• Actual: {"status": "error"} → ❌ Failed

XPath Check (XPath Assertion) - For XML

Performs check using XPath in XML responses:

Activate Toggle

Activate the "XPath Result" toggle

Enter XPath

Enter the XPath expression in the XPath field

Enter Expected Value

Enter the expected value in the Expected XPath Result field

Example:

• XPath: /response/status
• Expected Result: success
• Actual XML: <response><status>success</status></response> → ✅ Successful

JSONPath Check (JSONPath Assertion) - For JSON

Performs check using JSONPath in JSON responses:

Activate Toggle

Activate the "JsonPath Result" toggle

Enter JSONPath

Enter the JSONPath expression in the JsonPath field

Enter Expected Value

Enter the expected value in the Expected JsonPath Result field

Example:

• JSONPath: $.status
• Expected Result: ok
• Actual JSON: {"status": "ok", "data": {...}} → ✅ Successful

Common JSONPath Examples:

• $.status: Status field at root
• $.data.items[0].id: ID of first item
• $.user.name: Name field of user object
• $.results[*].id: IDs of all results

Step 5: Settings

Timeout - Default: 30 seconds

Determines the maximum wait time for the request:

• Entered in seconds
• Default value: 30 seconds
• If no response is received within this time, test is considered failed

ipucu

Recommendations:

• For fast APIs: 10-15 seconds
• For normal APIs: 30 seconds
• For slow APIs: 60 seconds or more

SSL Certificate (Enable Certificate)

To use SSL certificate for HTTPS requests:

• When this option is activated, custom SSL certificate can be used
• Generally used for self-signed certificates or custom CA certificates

Step 6: Retry Settings

To automatically retry in case of temporary issues:

Retry On Fail

Activate Toggle

Activate the "Retry On Fail" toggle

Select Number

Select "Retry Count": 1, 3, 5, or 10

How It Works:

• If the first request fails
• Retries are made up to the specified number
• Wait can be made between each attempt (optional)

Example Scenario:

• Retry Count: 3
• First request failed → 1st retry → failed → 2nd retry → failed → 3rd retry → successful → ✅ Successful

Delay Between Requests

To wait between retries:

Activate Toggle

Activate the "Delay Between Requests" toggle

Enter Wait Time

Enter the wait time in seconds in the "Wait" field

Default Value: 3 seconds

Use Case:

• To reduce server load
• To avoid rate limiting
• To give time for temporary issues to resolve

Example:

• Retry Count: 3
• Wait: 5 seconds
• First request failed → wait 5 sec → 1st retry → failed → wait 5 sec → 2nd retry → successful

Step 7: Notification Recipients

Configure notifications that will be triggered when the test fails:

Adding Notifications

Add Notification

Click the "+" button in the Recipients table

Select Notification Type

Select notification type:

• Email: Sends email notification
• Webhook: Sends HTTP POST request
• Slack: Sends message to Slack channel
• SMS: Sends SMS notification
• And more...

Complete Configuration

Complete the notification configuration

Notification Management:

• Edit: Select "Edit" from the menu to update notification information
• Delete: Select "Delete" from the menu to remove the notification
• Active/Passive: You can activate/deactivate the notification with toggle

Notification Content: The following information is sent in notifications:

• Health check name
• Proxy name (if any)
• Target URL
• Error message
• Timestamp
• Test result details

Step 8: Saving

After filling in all information:

Validation Check

Make sure form validations pass:

• ✅ Name entered and available
• ✅ URL entered
• ✅ Scheduling settings configured
• ✅ At least one assertion active (recommended)

Save

Click the "Save" button

Redirect

After the health check is saved, you will be automatically redirected to the listing page

Monitoring and Reporting Results

Accessing Results Page

Access from List

Click on the check name in the health check list

Access from Menu

Select "Results" option from the operations menu (⋮)

Results Page Sections

1. Header Section

• Date Range Selector: Filter results by a specific date range
• Refresh Button: Manually refresh results
• HTTP Method and URL: Information about the tested endpoint

2. Status Summary

The general status of the health check is shown at the top of the page:

Response Time Graph:

• Line graph showing response times over time
• X axis: Date/Time
• Y axis: Response time (milliseconds)
• You can see detailed information by hovering over the graph

Average Response Time:

• Average response time of all tests (milliseconds)
• Shown in large and bold text
• Important metric for performance evaluation

Success Rate:

• Ratio of successful tests to total tests (percentage)
• Green: Good performance (95%+)
• Yellow: Medium performance (80-95%)
• Red: Low success rate (below 80%)

Status summary and test results table

3. Test Results Table

Table showing detailed results of each test run:

Columns:

• Request Sent: Date and time when the test request was sent
• Request Type:
• Initial Request: Normal test request
• Retry: Retry request
• Response Time: Response time of the request (milliseconds)
• Assertions: Checks performed and their results:
• ✅ Timeout: Request did not timeout
• ✅ Status Code: Expected HTTP status code returned
• ✅ Result Body: Response body validated
• ✅ XPath: XPath check successful (for XML)
• ✅ JSONPath: JSONPath check successful (for JSON)
• Result:
• 🟢 Successful: All checks passed
• 🔴 Failed: At least one check failed
• Detail: Eye icon (👁️) to view result details in JSON format

Viewing Result Details

Click Detail Button

Click the eye icon (👁️) button in the table

Review Details

In the opened dialog, you can view all details of the test result in JSON format:

• Request information (URL, method, headers, body)
• Response information (status code, headers, body)
• Assertion results (result of each check)
• Error messages (if any)
• Timestamps

Deleting All Results

uyarı

This operation cannot be undone! All historical data will be lost.

Click Delete Button

Click the trash can (🗑️) icon in the table header

Deletion Completed

All results are permanently deleted

Health Check Management

List Page Features

On the health check list page, you can view and manage all your checks.

Search and Filtering

• Search by Name: Filter checks by typing in the name field
• Search by Description: Search by typing in the description field
• Project Filter (Admin mode): View checks from multiple projects
• Clear: Click the eraser icon to clear all filters

Table Columns

• Name: Health check name (clickable, goes to results page)
• Description: Check description
• Target URL: URL of the tested endpoint
• Status: Active/Passive status (can be changed with toggle)
• Project (Admin mode): Project the check belongs to
• Operations: Menu button (⋮)

Operations Menu

For each check, click the menu button (⋮) to perform the following operations:

1. Results: View check execution results
2. Edit: Update check settings
3. Delete: Delete the check
4. Move to Global (if project check): Move check to global project

Changing Status

To change the active/passive status of the check:

Click Toggle

Click the toggle in the Status column in the table

Status Updated

Check status is updated instantly

Passive Checks

Passive checks do not run, but their historical data is preserved

Best Practices

1. Naming Conventions

• Use Descriptive Names: Clear names like Payment API Check
• Add Project/Module Prefix: Like E-Commerce - Payment API
• Add Environment Information: Like Production - User API

2. Scheduling Strategy

• Critical APIs: Check every 5 minutes
• Normal APIs: Check every 15-30 minutes
• Test Environments: Check every hour
• Consider server load

3. Assertion Usage

• Use at least one assertion (Status Code recommended)
• Always activate timeout assertion
• Use body assertions carefully (if variable content exists)
• Make specific checks using JSONPath/XPath

4. Retry Strategy

• Use retry for temporary issues
• Keep retry count reasonable (between 3-5)
• Reduce server load by using delay
• Increase delay in rate limiting situations

5. Notification Management

• Use email + SMS notification for critical checks
• Send notifications to your integration systems using Webhook
• Filter to avoid notification spam
• Create notification groups

6. Performance Monitoring

• Regularly check response times
• Track success rates (aim for 95%+)
• Perform trend analysis (examine graphs)
• Set threshold values for anomaly detection

Frequently Asked Questions

How Often Does Health Check Run?

The frequency of check execution depends on the Scheduling (Cron Expression) settings you determined when creating it. For example:

• 0 */5 * ? * * → Every 5 minutes
• 0 0 * ? * * → Every hour
• 0 0 9 * ? * → Every day at 09:00

What Happens When Check is Deactivated?

When check is deactivated:

• No new test requests are sent
• Existing scheduled jobs are cancelled
• Historical results are preserved and can be viewed
• Check continues normal operation when reactivated

How Does Retry Work?

When "Retry On Fail" feature is activated:

1. First request is sent
2. If it fails (any assertion fails)
3. Retries are made up to the number you specified
4. If there is wait between requests, wait for the specified duration
5. If all attempts fail, result is recorded as "Failed"

When Are Notifications Sent?

Notifications (Recipients) are triggered in the following situations:

• When test fails
• Separate notification is sent for each failed test
• Notifications are not sent for successful tests (default behavior)

How Do Assertion Checks Work?

Assertion checks are performed in the following order:

1. Timeout Check: Was the request responded to within the specified time?
2. Status Code Check: Does HTTP status code match the expected value?
3. Body Check: Does response body match the expected content?
4. XPath Check: Does XPath expression give correct result in XML response?
5. JSONPath Check: Does JSONPath expression give correct result in JSON response?

uyarı

Important: All active assertions must be successful. If any one fails, the test result is marked as "Failed".

What is the Use of Selecting from Test Collection?

The select from test collection feature allows you to reuse test scenarios you previously created in Test Console. This way:

• You save time
• You use consistent test scenarios
• You can manage your test scenarios centrally

What Happens When Check is Deleted?

When check is deleted:

• Check definition is deleted from database
• All test results are deleted
• Scheduled jobs are cancelled
• Historical data is permanently lost

uyarı

Deletion cannot be undone!

How Long Are Results Kept?

Results are kept until manually deleted. To clean old results:

• You can use the "Delete All Results" button on the results page
• Or you can clean results regularly

Can I Use Multiple Assertions?

Yes, you can use multiple assertions. All active assertions must be successful. For example:

• Status Code: 200 ✅
• "success" text in Body ✅
• JSONPath: $.status = "ok" ✅

If all are successful, test is considered successful.

Can I Use Dynamic Parameters in URL?

No, dynamic parameters cannot be used in URL. However:

• You can add query parameters
• You can use dynamic values in headers (in some cases)
• You can use dynamic content in body

Troubleshooting

Check Not Working

Possible Causes:

1. Check may be in passive status → Check status toggle
2. Scheduling settings may be wrong → Check cron expression
3. URL may not be accessible → Test URL manually

Solution:

• Activate check status
• Check scheduling settings
• Make sure URL is accessible

All Tests Failing

Possible Causes:

1. URL is wrong or not accessible
2. Assertion settings are too strict
3. Timeout duration is too short
4. Authentication issues

Solution:

• Check URL
• Review assertion settings
• Increase timeout duration
• Check authentication information in headers

Notifications Not Coming

Possible Causes:

1. Notification is in passive status
2. Notification configuration is incorrect
3. Email/SMS service is not working

Solution:

• Activate notification status
• Check notification configuration
• Check Email/SMS service settings

Response Times Too High

Possible Causes:

1. API performance issues
2. Network delays
3. Server load

Solution:

• Optimize API performance
• Check network connection
• Check server resources

Results Not Showing

Possible Causes:

1. Check has not run yet
2. Date range filter is wrong
3. Results may have been deleted

Solution:

• Make sure check has run
• Check date range filter
• Make sure results have not been deleted

Additional Resources

Test Console Usage Guide

Creating test scenarios

Connectors

Notification and action configuration

Scheduled Jobs

Scheduling settings and cron expression

API Documentation

REST API usage