Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Welcome to Software Development on Codidact!

Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.

Comments on What should healthcheck of an Web API application actually check?

Parent

What should healthcheck of an Web API application actually check?

+1
−0

I have to add health checks to a rather new application (Web API, not a microservice) and I and a colleague are not agreeing about what other systems I should include in the check. This application is the beginning of the writing of a legacy one (will work side by side for a long transition period).

The following systems to be included are considered:

  • the relational database this application is querying
  • an external API that the application is querying once a day (sync some identities)
  • the legacy application

My opinion is that only the database check should be currently included because it it fails nothing works. For the other systems, if they fail I do not really care, unless the API fails when I need to sync the data.

I am interested in a guideline to understand how dependencies are considered when building the health check functionality for an API.

Additional details about the usage: currently none of these services will be deployed as microservices (yet) and a failed health-check (actually multiple in a row, as configured in a monitoring system) will trigger an e-mail notification. Naturally, I would like to minimize the false positive failed health checks.

The debate is whether to include dependencies such as the external API in the check since I only use it once a day. My opinion is that my system should not care whether if it fails, as long as I can sync my data when I need it, but I have never designed any serious monitoring for an app and I might be wrong with this one.

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.
Why should this post be closed?

0 comment threads

Post
+4
−0

I am interested in a guideline to understand how dependencies are considered when building the healthcheck functionality for an API.

Like any functionality, the implementation of this feature should be guided by specific requirements. Who will be using that feature? What for?

For instance, if this healthcheck is an endpoint for a kubernetes liveness probe (which causes an automatic restart of the pod if it deems itself unhealthy), including external systems doesn't make sense, because restarting your app won't fix these systems.

On the other hand, if the health check is used by an actual human, they might be able to interpret a more nuanced response, and prefer being informed when optional dependencies fail.

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.

1 comment thread

General comments (1 comment)
General comments
Alexei‭ wrote almost 4 years ago

Indeed my post lacked important information about the usage. I edited the post, but your answer is very useful anyway. Thanks.