Feature Description
Currently, the server does not expose a dedicated health check endpoint to verify whether core services like the backend server, database, and Redis are functioning correctly.
Adding a simple health check route would make deployment monitoring, Docker health checks, CI/CD verification, and uptime tracking much easier.
Use Case / Problem Statement
Without a health endpoint, it is difficult to:
- Confirm if the backend server is running properly
- Verify database connectivity in production
- Check Redis availability for real-time features
- Integrate with monitoring tools or container health checks
This feature would improve reliability, observability, and production readiness of the BrowsePing server.
Proposed Solution
Create a new endpoint:
GET /health
Expected JSON response when healthy:
{
"status": "ok",
"database": "connected",
"redis": "connected",
"timestamp": "ISO_STRING"
}
If any dependency fails, return:
- HTTP 500 status
- JSON response with "status": "error"
Implementation should:
- Check MySQL connection via Prisma
- Ping Redis connection
- Return structured JSON response
- Work in both Docker and local environments
- Be documented in README
Alternative Solutions
Monitoring could be handled externally using container orchestration or third-party uptime tools, but a built-in health endpoint is the standard and simplest approach for backend services.
Additional Context
Health check endpoints are commonly used in production systems for:
- Load balancer health verification
- Kubernetes/Docker container health checks
- CI/CD deployment validation
- Observability and uptime monitoring
Adding this endpoint would align BrowsePing with backend best practices.
Checklist
Feature Description
Currently, the server does not expose a dedicated health check endpoint to verify whether core services like the backend server, database, and Redis are functioning correctly.
Adding a simple health check route would make deployment monitoring, Docker health checks, CI/CD verification, and uptime tracking much easier.
Use Case / Problem Statement
Without a health endpoint, it is difficult to:
This feature would improve reliability, observability, and production readiness of the BrowsePing server.
Proposed Solution
Create a new endpoint:
GET /health
Expected JSON response when healthy:
{
"status": "ok",
"database": "connected",
"redis": "connected",
"timestamp": "ISO_STRING"
}
If any dependency fails, return:
Implementation should:
Alternative Solutions
Monitoring could be handled externally using container orchestration or third-party uptime tools, but a built-in health endpoint is the standard and simplest approach for backend services.
Additional Context
Health check endpoints are commonly used in production systems for:
Adding this endpoint would align BrowsePing with backend best practices.
Checklist