Health & Monitoring
Monitor API health and service availability. All health endpoints are public and require no authentication for easy integration with monitoring tools.
No Authentication Required
All health check endpoints are public and accessible without JWT tokens or API keys. Perfect for uptime monitoring services like Pingdom, UptimeRobot, or Datadog.
Gateway Health
/healthOverall gateway health status. This endpoint checks if the API gateway is running and able to serve requests.
About This Endpoint
Query the API's operational status to verify it can accept and process HTTP requests. This lightweight endpoint requires no authentication and returns instantly, making it ideal for uptime monitoring services and health check integrations. The response includes service version for tracking deployments and uptime in seconds to monitor service stability. Use this as your primary entry point for monitoring overall API availability.
Response Fields
- status: "healthy" indicates API is operational and accepting requests
- version: Current deployment version for tracking releases
- uptime: Seconds since service started, useful for detecting recent restarts
Integration Points
- Uptime monitoring services (Pingdom, UptimeRobot, StatusCake) for SLA tracking
- External monitoring tools for alerting and incident management
- Automated health checks to verify API availability
Response Example
{
"status": "healthy",
"service": "api-gateway",
"version": "1.2.3",
"timestamp": "2025-10-12T10:00:00.000Z",
"uptime": 864000
}CDR Health
/api/v1/cdr/healthCDR processor service health including database connectivity and processing status.
About This Endpoint
Monitor call detail record processing service health including database connectivity for CDR storage and query operations. This endpoint validates that CDR ingestion, storage, and retrieval can function properly by testing database connections and measuring query latency. The response indicates whether the service can accept new call records and serve CDR queries without degradation.
Health Checks
- Database connectivity for CDR storage and retrieval operations
- Processing queue status to ensure CDR ingestion is functioning
- Query performance validation for CDR list and search endpoints
Monitoring Focus
- Verify database connections to ensure CDRs are being stored reliably
- Monitor response latency to detect query performance issues
- Check service status before querying large CDR datasets
Response Example
{
"status": "healthy",
"service": "cdr-processor",
"version": "1.0.0",
"timestamp": "2025-10-12T10:00:00.000Z",
"dependencies": {
"database": {
"status": "connected",
"type": "postgresql",
"latency": 4
}
}
}Monitoring Best Practices
Health Check Frequency
Poll health endpoints every 30-60 seconds for production systems. Avoid excessive polling (<10s intervals) which may impact service performance.
Alert Thresholds
Set up alerts when any service returns non-200 status code or when response time exceeds 5 seconds. Configure escalation after 3 consecutive failures to reduce false positives.
Status Codes
200 OK: Service is healthy and all dependencies are operational
503 Service Unavailable: Service is degraded or dependencies are failing
500 Internal Server Error: Critical service failure requiring immediate attention
Dependency Monitoring
Each health response includes dependency status (database, Redis, external APIs). Monitor these fields to identify which component is causing failures. Database latency should be <10ms, Redis <5ms, external APIs <200ms.
Uptime Monitoring Tools
Recommended tools: UptimeRobot (free tier available), Pingdom, StatusCake, Datadog Synthetic Monitoring, or AWS CloudWatch. Configure multi-location checks to detect regional outages.
Response Time Baselines
Typical health check response times:
Gateway: 5-20ms | Account Service: 10-50ms | Trunk Service: 10-50ms
Balance Service: 15-60ms | Number Service: 50-200ms (Twilio API dependency)