Monitor

Keep your APIs running smoothly with Quetzly Validator's monitoring feature. Set up continuous monitoring of your critical endpoints to track uptime, performance, and view issues before they impact your users.

What is API Monitoring?

API monitoring is the continuous checking of your endpoints to ensure they:

• Respond successfully: Return expected HTTP status codes
• Perform adequately: Meet response time requirements
• Stay available: Remain accessible when needed
• Function correctly: Return expected data formats and content

Monitoring now supports service-level assertion checks for ArcGIS Map Services and Feature Services, giving you deeper insight beyond just HTTP status codes.

Accessing the Monitor Interface

1. Click the Monitor icon in the left sidebar
2. The Monitor panel displays:
   • Add API Endpoint: Configure new endpoints for monitoring
   • Monitoring Interval: Set check frequency
   • Monitor Table: View status of all monitored endpoints

Setting Up Endpoint Monitoring

Adding API Endpoints

Step 1: Add Endpoint URL

1. Enter the API endpoint URL in the "Enter API Endpoint URL" field
2. Examples of endpoints to monitor:

   # WMS GetCapabilities
   https://example.com/geoserver/wms?service=WMS&request=GetCapabilities
   
   # REST API health check
   https://api.example.com/v1/health
      
   # ArcGIS service status
   https://services.arcgis.com/example/arcgis/rest/services/layer/MapServer
   
   # WFS service availability
   https://example.com/geoserver/wfs?service=WFS&request=GetCapabilities

3. Enable Assertions (optional): A toggle next to the Add button controls whether service-level assertion checks are run when the endpoint is added. It is enabled by default. When enabled and the service returns a 200 status, Quetzly runs additional checks for ArcGIS Map Services and Feature Services (see Assertion Checks below).
4. Click "Add" to add the endpoint to your monitoring list

Step 2: Configure Monitoring Interval

Set Check Frequency:

1. Enter a number in the "Interval Time" field

2. Select the time unit from the dropdown:

   • seconds: For high-frequency monitoring (use sparingly)
   • minutes: Most common for active monitoring
   • hours: For less critical services
   • days: For basic availability checks

3. Click "Save" to apply the monitoring interval to all endpoints

Monitor Configuration Best Practices

Choosing Monitoring Intervals

Consider these factors:

• Service criticality: More critical = more frequent checks
• Service stability: Unstable services may need frequent monitoring
• Resource usage: Frequent checks consume more resources
• Provider limits: Respect API rate limits and terms of service

Endpoint Selection

Recommended endpoints to monitor:

• ✅ Service health/status endpoints: Dedicated health check URLs
• ✅ GetCapabilities requests: For WMS/WFS service availability
• ✅ Root service endpoints: Main service entry points
• ✅ Authentication endpoints: Login and token services
• ✅ Critical data endpoints: Your most important data sources

Avoid monitoring:

• ❌ Rate-limited endpoints: Those with strict usage limits
• ❌ Resource-intensive queries: Complex requests that stress servers
• ❌ User-specific endpoints: URLs requiring user authentication
• ❌ Deprecated services: Services scheduled for retirement

Understanding the Monitor Table

The monitoring table displays real-time status information for all your monitored endpoints:

Table Columns

URL

• Display: Shows the monitored endpoint URL
• Truncation: Long URLs may be abbreviated
• Tooltip: Hover to see the complete URL

Date

• Format: Shows the date of the last check
• Updates: Refreshes after each monitoring cycle
• Time zone: Displays in your local time zone

Status

Displays the result of the last check. Hover over the icon to see a detailed tooltip.

When assertions are disabled (or the service is not an ArcGIS Map/Feature service):

• The HTTP status code is shown with a brief description
• 🟢 (check icon): HTTP 200 OK
• 🔴: Non-200 status with error description

When assertions are enabled for ArcGIS Map Services and Feature Services:

• 🟢 All assertion checks passed
• ⚠️ Some checks failed but no critical issues detected
• 🔴 One or more critical failures (e.g. no layers, bad status, unreachable)

Hovering the icon shows a tooltip listing each Passed check (green) and each Failed check (red).

Actions

• Remove: Delete the endpoint from monitoring

Interpreting Status Codes

Success Codes (2xx):

• 200 OK: Perfect response, service is healthy
• 201 Created: Successful resource creation
• 204 No Content: Successful request with no response body

Redirect Codes (3xx):

• 301/302: Service moved, may need URL update
• 304 Not Modified: Cached response, normal for some services

Client Error Codes (4xx):

• 400 Bad Request: Malformed monitoring request
• 401 Unauthorized: Authentication required
• 403 Forbidden: Access denied
• 404 Not Found: Service endpoint not available
• 429 Too Many Requests: Rate limit exceeded

Server Error Codes (5xx):

• 500 Internal Server Error: Service experiencing issues
• 502 Bad Gateway: Proxy/gateway error
• 503 Service Unavailable: Service temporarily down
• 504 Gateway Timeout: Service response timeout

Assertion Checks

When Enable Assertions is toggled on and an endpoint returns HTTP 200, Quetzly runs a suite of service-level checks on ArcGIS Map Services and Feature Services to verify the service is healthy beyond just connectivity.

ArcGIS Map Service Assertions

Checks performed against a /MapServer endpoint:

Check	What it verifies
Service reachable	HTTP 200 returned from the service endpoint
Has layers	The service defines at least one layer
Spatial reference	WKID is consistent with the coordinate values in the extent
Export map	A map export request returns a valid image response

ArcGIS Feature Service Assertions

Checks performed against a /FeatureServer endpoint:

Check	What it verifies
Service reachable	HTTP 200 returned from the service endpoint
Spatial reference defined	The service has a spatial reference set
Spatial reference consistent	WKID is consistent with the coordinate values in the extent
Has layers/tables	The service defines at least one layer or table
Feature counts	Each layer contains at least one feature

Status Icons

After assertion checks run, the status icon in the monitor table reflects the result:

• 🟢 — All checks passed
• ⚠️ — Some checks failed, but no critical issues
• 🔴 — Critical failure (e.g. no layers defined, service unreachable, bad status)

Hover over the icon to see the full breakdown of passed and failed checks.