Skip to main content

Monitor

Keep your APIs running smoothly with Quetzly's monitoring system. 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

Note: at the moment only basic monitoring is performed on APIs to get returned HTTP status. More monitoring information and features are planned for future releases.

Accessing the Monitor Interface​

  1. Click the Open 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. 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​

  • HTTP Codes: Displays the last received HTTP status code
  • Color Coding:
    • 🟢 Green (2xx): Service is healthy and responding
    • 🟡 Yellow (3xx): Redirects or warnings
    • 🔴 Red (4xx/5xx): Client or server errors

Actions​

  • Remove: Delete the endpoint from monitoring
  • More actions like test now and view detailed response are coming soon.

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

Monitoring Workflows​

Production Monitoring​

Critical Service Monitoring​

  1. Identify your most critical API endpoints
  2. Set more aggressive monitoring intervals
  3. Monitor both service availability and key functionality
  4. Document expected response characteristics
  5. Establish escalation procedures for failures

Comprehensive Coverage​

  • Primary services: Core business functionality
  • Dependency services: External APIs your application relies on
  • Health check endpoints: Dedicated monitoring endpoints
  • Geographic redundancy: Monitor from multiple locations if possible

Development and Testing​

Development Environment Monitoring​

  • Monitor development services during active development
  • Use longer intervals to reduce noise
  • Track stability during testing phases
  • Monitor deployment processes and post-deployment health

Integration Testing​

  • Monitor service interactions
  • Check data flow between services
  • Verify third-party integrations
  • Test failover and recovery scenarios

Incident Response​

When Monitoring Detects Issues​

Immediate Actions:

  1. Verify the issue isn't a false positive
  2. Check multiple endpoints to determine scope
  3. Review recent changes or deployments
  4. Escalate according to your incident response plan

Investigation Steps:

  1. Manual testing: Test the endpoint manually in Quetzly
  2. Check dependencies: Verify related services are running
  3. Review logs: Check application and infrastructure logs
  4. Network verification: Ensure network connectivity

Communication:

  • Alert stakeholders: Notify relevant team members
  • Status updates: Provide regular updates on investigation
  • Resolution notification: Communicate when issues are resolved
  • Post-incident review: Document lessons learned

Troubleshooting Monitoring Issues​

Common Problems​

Endpoints not being checked:

  1. Verify the URL is correct and accessible
  2. Check that monitoring interval is saved
  3. Confirm the application is running continuously
  4. Review any error messages in the interface

False positive alerts:

  1. Test manually: Use the API section to test the endpoint
  2. Check network: Verify your internet connection
  3. Review timing: Consider if interval is too aggressive
  4. Examine responses: Look for intermittent issues

Missing monitoring data:

  1. Check that monitoring has been running continuously
  2. Verify the application hasn't been closed
  3. Review system resources (CPU, memory, network)
  4. Restart remove and add API again

Performance Optimization​

Reducing resource usage:

  • Optimize intervals: Use appropriate check frequencies
  • Limit endpoints: Monitor only essential services
  • Batch requests: Group similar checks where possible
  • Resource monitoring: Monitor Quetzly's own resource usage

Network considerations:

  • Bandwidth usage: Factor in monitoring traffic
  • Rate limits: Respect API provider limitations
  • Geographic proximity: Consider monitoring from appropriate locations
  • Concurrent requests: Manage simultaneous monitoring requests

Best Practices​

Monitoring Strategy​

Endpoint Selection​

  • Start small: Begin with a few critical endpoints
  • Expand gradually: Add more endpoints as you gain experience
  • Regular review: Periodically assess monitoring value
  • Remove unused: Clean up monitoring for deprecated services

Interval Management​

  • Match criticality: More critical services need frequent checks
  • Consider resources: Balance monitoring frequency with resource usage
  • Respect limits: Follow API provider guidelines
  • Adjust as needed: Modify intervals based on experience

Documentation​

  • Document purpose: Why each endpoint is being monitored
  • Record expectations: What constitutes healthy vs. unhealthy
  • Maintain contacts: Who to notify for different types of issues
  • Update procedures: Keep incident response plans current

What's Next?​

Now that you understand API monitoring:

  • Return to Send Requests to test endpoints before monitoring
  • Use Sets to save monitoring configurations
  • Review History to identify which endpoints deserve monitoring
  • Start with Getting Started if you need to set up Quetzly

You now have complete knowledge of Quetzly's core features. Use this documentation as a reference as you develop your API testing and monitoring workflows!