Feature Description:
I propose the implementation of a dedicated health check endpoint. This endpoint would serve the sole purpose of allowing users to verify the service's liveness without influencing the statistics related to short URL visits.
Problem:
Currently, to monitor Shlink's availability, I've had to create a short URL specifically for this purpose and use it with a monitoring service. While effective in ensuring the service's health, this approach inadvertently inflates the visit statistics, making them less reflective of actual user engagement. For context, the "visits" stats now show an inflated number of 2,227,774 due to the monitoring pings.
Use case
Proposed Solution:
A dedicated endpoint, such as /health or /status, could return a simple HTTP 200 status code if the service is up and running. This would provide an accurate method for health checks without affecting the visit statistics of any short URLs.
Benefits:
Improved accuracy of visit statistics.
A standardized way to monitor Shlink's service health.
Reduced overhead for users who currently implement workarounds for service monitoring.
I believe this feature would be a valuable addition for all Shlink users who rely on external monitoring tools to ensure the service's availability.
Thank you for considering this request. I look forward to your thoughts and am happy to contribute to the discussion or implementation if needed.
Summary
Feature Description: I propose the implementation of a dedicated health check endpoint. This endpoint would serve the sole purpose of allowing users to verify the service's liveness without influencing the statistics related to short URL visits.
Problem: Currently, to monitor Shlink's availability, I've had to create a short URL specifically for this purpose and use it with a monitoring service. While effective in ensuring the service's health, this approach inadvertently inflates the visit statistics, making them less reflective of actual user engagement. For context, the "visits" stats now show an inflated number of 2,227,774 due to the monitoring pings.
Use case
Proposed Solution: A dedicated endpoint, such as /health or /status, could return a simple HTTP 200 status code if the service is up and running. This would provide an accurate method for health checks without affecting the visit statistics of any short URLs.
Benefits:
I believe this feature would be a valuable addition for all Shlink users who rely on external monitoring tools to ensure the service's availability.
Thank you for considering this request. I look forward to your thoughts and am happy to contribute to the discussion or implementation if needed.
Best regards, David Duman