Enhance Health Check Endpoint with Detailed Service Information

[aphansal123]

Problem

The current health check endpoint (/v0/health) only returns basic status information. For a production service, we need more comprehensive health information to properly monitor the service and diagnose issues.

Current Behavior

{
  "status": "ok",
  "github_client_id": "client_id_here"
}

Proposed Enhancement

Add additional health information including:

• Database connectivity status
• Service dependencies status
• Memory usage
• Uptime information
• Version information

Expected Response

{
  "status": "ok",
  "github_client_id": "client_id_here",
  "database": {
    "status": "connected",
    "type": "mongodb",
    "collection_count": 1
  },
  "uptime": "2h30m15s",
  "version": "v0.1.0",
  "memory": {
    "alloc": "2.1MB",
    "sys": "8.5MB"
  }
}

Technical Details

• Modify internal/api/handlers/v0/health.go
• Add database connectivity check
• Include runtime metrics
• Maintain backward compatibility

Acceptance Criteria

• Database connection status is checked and reported
• Service uptime is included
• Memory usage is reported
• Version information is included
• Existing response format is maintained (backward compatible)
• Health check responds quickly (< 100ms)

Labels

• enhancement
• good first issue
• monitoring

[BrunoPolaski]

Hey, @aphansal123 , I'm a beginner in open source projects and I'd like to implement this feature. Do you know if the feature needs any approval of the repo creators to proceed?

[aphansal123]

Hey, @aphansal123 , I'm a beginner in open source projects and I'd like to implement this feature. Do you know if the feature needs any approval of the repo creators to proceed?

@BrunoPolaski Hi Bruno, thanks for checking, good question - I think it may need to be approved by one of the repo creators but I'm not 100% sure. I would definitely check with them though.

[tadasant]

This is a reasonable issue and we'd review/merge a contribution!

[shenyv1]

/assign
could you please assign this to me ?

[shenyv1]

hi,I've submitted my PR (#209) addressing the mentioned issue, but I'd appreciate your review on a few points I'm uncertain about:

​​--Database Connection Handling​​:The health check requires a database.Databaseinstance to call related methods, but this wasn't originally passed through the router. I've added database.Databaseto the parameter chain across main → server → router → v0 → health. Please let me know if this approach aligns with the project's design.
--​​Version Information​​:While version.goin the mainpackage already defines the version, directly accessing it from the healthpackage would create a circular dependency. As a workaround, I created an appinfopackage to declare the version. Perhaps we could later move this to a shared utility package?
​​--Other Potential Issues​​:I’d be grateful if you could point out any other areas that may need adjustment.
Thank you for your time and guidance. I’m happy to revise the PR based on your feedback.

[tadasant]

@toby do you mind tackling this review/feedback (or tapping someone from the GH team to do so)?

[shenyv1]

Hi @toby,

Thank you again for your time and the opportunity to contribute. As a newcomer to open source, I’m eager to learn and continue contributing to this project. Could you or someone from the team kindly provide feedback on this PR when convenient?

I understand everyone is busy, so please let me know if there’s anything I can clarify or improve in the meantime. Your guidance would be greatly appreciated!

[domdomegg]

Hey, I've assigned the PR to @aphansal123 review.

Some thoughts about this issue: I think the main health check should probably be lighter? I imagine this mainly be used as a 'is the service up' type endpoint, and adding more stuff slows this down and adds complexity.

I think there is a need for observability of the app - but shoving some top level metrics into the health check endpoint probably isn't the right way to go. I think I'd prefer:

• (ideal) Reporting metrics out in some standard way, e.g. a prometheus /metrics endpoint, or via OpenTelemetry
• Reporting metrics out at least on a different endpoint, and probably one that's not on the registry OpenAPI spec