feat: Add API health check route

[HuiNeng6]

Implements GET /api/health endpoint for monitoring.

Returns status UP, uptime in seconds, and timestamp.

Fixes: #4

[qodo-code-review]

Review Summary by Qodo

Add API health check endpoint for monitoring

✨ Enhancement

Walkthroughs

Description

• Adds GET /api/health endpoint for server monitoring
• Returns status, uptime in seconds, and ISO timestamp
• Integrates health check route into main Express application

Diagram

flowchart LR
  A["index.ts"] -- "imports" --> B["health.ts"]
  B -- "defines GET /api/health" --> C["Health Check Endpoint"]
  C -- "returns" --> D["status, uptime, timestamp"]
  A -- "registers route" --> E["app.use /api/health"]

Loading

File Changes

1. backend/src/index.ts ✨ Enhancement +2/-0

Register health check route in main app

• Imports the new health routes module
• Registers the health check route at /api/health path
• Integrates health endpoint into Express application middleware stack

backend/src/index.ts

---

2. backend/src/routes/health.ts ✨ Enhancement +24/-0

Implement health check endpoint route

• Creates new health check route handler with GET endpoint
• Tracks server start time and calculates uptime in seconds
• Returns JSON response with status UP, uptime, and ISO timestamp
• Includes JSDoc documentation for the endpoint

backend/src/routes/health.ts

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (0) 📎 Requirement gaps (0) 📐 Spec deviations (0)

1. Health always reports UP 🐞 Bug ⛯ Reliability

Description

GET /api/health always returns HTTP 200 with status "UP" without checking critical dependencies
(notably the Prisma/DB connection), so monitoring/load-balancers can treat the instance as healthy
while core API operations fail due to database outages.

Code

backend/src/routes/health.ts[R13-22]

+router.get('/', (req: Request, res: Response) => {
+  const now = new Date();
+  const uptimeSeconds = Math.floor((Date.now() - startTime) / 1000);
+  
+  res.status(200).json({
+    status: 'UP',
+    uptime: uptimeSeconds,
+    timestamp: now.toISOString(),
+  });
+});

Evidence

The health route responds with 200/UP unconditionally. The service relies on Prisma for core
operations (e.g., auth), so DB unavailability can break user-facing endpoints while /api/health
still reports healthy.

backend/src/routes/health.ts[13-22]
backend/src/index.ts[15-17]
backend/src/controllers/authController.ts[1-3]
backend/src/controllers/authController.ts[12-21]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`GET /api/health` currently returns `200` and `{ status: 'UP' }` regardless of whether core dependencies (notably the database via Prisma) are actually usable. This can cause false-positive health signals during DB outages.

## Issue Context
The backend instantiates a `PrismaClient` and controllers (e.g., auth) depend on it for request handling. A meaningful health check should reflect whether the service can perform its primary responsibilities.

## Fix Focus Areas
- backend/src/routes/health.ts[13-22]
- backend/src/index.ts[15-17]

## Suggested fix
- Make the handler `async` and perform a lightweight Prisma check (e.g., `await prisma.$queryRaw\`SELECT 1\`` or `await prisma.$executeRaw\`SELECT 1\``).
- On failure, return `503` with `status: 'DOWN'` (and optionally include per-dependency check statuses).
- Ensure the Prisma client used is the same long-lived instance (avoid creating a new PrismaClient per request).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Uptime measured from import 🐞 Bug ✓ Correctness

Description

The health endpoint computes uptime from a module-level startTime set at import time, which can be
earlier than when the process is actually ready to serve requests and can reset on module reloads,
making the metric less accurate for monitoring.

Code

backend/src/routes/health.ts[R5-16]

+// Store server start time
+const startTime = Date.now();
+
+/**
+ * GET /api/health
+ * Health check endpoint for monitoring and setup verification
+ * Returns server status, uptime, and timestamp
+ */
+router.get('/', (req: Request, res: Response) => {
+  const now = new Date();
+  const uptimeSeconds = Math.floor((Date.now() - startTime) / 1000);
+  

Evidence

startTime is initialized when the module is imported. Since the server imports routes before
calling app.listen(), the uptime includes pre-listen initialization time rather than true process
uptime.

backend/src/routes/health.ts[5-16]
backend/src/index.ts[6-13]
backend/src/index.ts[38-40]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The health endpoint's `uptime` is based on a `startTime` captured at module import time, which is not the most accurate representation of actual process uptime.

## Issue Context
Routes are imported near the top of `src/index.ts` before `app.listen()` is invoked, so `startTime` is captured before the server is actually listening.

## Fix Focus Areas
- backend/src/routes/health.ts[5-16]

## Suggested fix
- Replace the `startTime`/`Date.now()` delta calculation with `Math.floor(process.uptime())`.
- Remove the module-level `startTime` constant to avoid unnecessary module initialization side effects.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

ⓘ The new review experience is currently in Beta. Learn more

[qodo-code-review]

1. Health always reports up 🐞 Bug ⛯ Reliability

GET /api/health always returns HTTP 200 with status "UP" without checking critical dependencies
(notably the Prisma/DB connection), so monitoring/load-balancers can treat the instance as healthy
while core API operations fail due to database outages.

Agent Prompt

## Issue description
`GET /api/health` currently returns `200` and `{ status: 'UP' }` regardless of whether core dependencies (notably the database via Prisma) are actually usable. This can cause false-positive health signals during DB outages.

## Issue Context
The backend instantiates a `PrismaClient` and controllers (e.g., auth) depend on it for request handling. A meaningful health check should reflect whether the service can perform its primary responsibilities.

## Fix Focus Areas
- backend/src/routes/health.ts[13-22]
- backend/src/index.ts[15-17]

## Suggested fix
- Make the handler `async` and perform a lightweight Prisma check (e.g., `await prisma.$queryRaw\`SELECT 1\`` or `await prisma.$executeRaw\`SELECT 1\``).
- On failure, return `503` with `status: 'DOWN'` (and optionally include per-dependency check statuses).
- Ensure the Prisma client used is the same long-lived instance (avoid creating a new PrismaClient per request).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

[qodo-code-review]

Review Summary by Qodo

Add API health check endpoint for monitoring

✨ Enhancement

Walkthroughs

Description

• Adds GET /api/health endpoint for server monitoring
• Returns status, uptime in seconds, and ISO timestamp
• Integrates health check route into main Express app

Diagram

flowchart LR
  A["index.ts"] -- "imports" --> B["health.ts"]
  B -- "defines GET /api/health" --> C["Health Check Endpoint"]
  C -- "returns" --> D["status UP, uptime, timestamp"]
  A -- "registers route" --> E["app.use /api/health"]

Loading

File Changes

1. backend/src/index.ts ✨ Enhancement +2/-0

Register health check route in Express app

• Imports new health routes module
• Registers health check route at /api/health endpoint
• Maintains existing route registration pattern

backend/src/index.ts

---

2. backend/src/routes/health.ts ✨ Enhancement +24/-0

Implement health check endpoint with monitoring data

• Creates new health check endpoint handler
• Tracks server start time for uptime calculation
• Returns JSON with status UP, uptime seconds, and ISO timestamp
• Includes JSDoc documentation for endpoint

backend/src/routes/health.ts

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (0) 📎 Requirement gaps (0) 📐 Spec deviations (0)

1. Health always reports UP 🐞 Bug ⛯ Reliability

Description

GET /api/health always returns HTTP 200 with status "UP" without checking critical dependencies
(notably the Prisma/DB connection), so monitoring/load-balancers can treat the instance as healthy
while core API operations fail due to database outages.

Code

backend/src/routes/health.ts[R13-22]

+router.get('/', (req: Request, res: Response) => {
+  const now = new Date();
+  const uptimeSeconds = Math.floor((Date.now() - startTime) / 1000);
+  
+  res.status(200).json({
+    status: 'UP',
+    uptime: uptimeSeconds,
+    timestamp: now.toISOString(),
+  });
+});

Evidence

The health route responds with 200/UP unconditionally. The service relies on Prisma for core
operations (e.g., auth), so DB unavailability can break user-facing endpoints while /api/health
still reports healthy.

backend/src/routes/health.ts[13-22]
backend/src/index.ts[15-17]
backend/src/controllers/authController.ts[1-3]
backend/src/controllers/authController.ts[12-21]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`GET /api/health` currently returns `200` and `{ status: 'UP' }` regardless of whether core dependencies (notably the database via Prisma) are actually usable. This can cause false-positive health signals during DB outages.
## Issue Context
The backend instantiates a `PrismaClient` and controllers (e.g., auth) depend on it for request handling. A meaningful health check should reflect whether the service can perform its primary responsibilities.
## Fix Focus Areas
- backend/src/routes/health.ts[13-22]
- backend/src/index.ts[15-17]
## Suggested fix
- Make the handler `async` and perform a lightweight Prisma check (e.g., `await prisma.$queryRaw\`SELECT 1\`` or `await prisma.$executeRaw\`SELECT 1\``).
- On failure, return `503` with `status: 'DOWN'` (and optionally include per-dependency check statuses).
- Ensure the Prisma client used is the same long-lived instance (avoid creating a new PrismaClient per request).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Uptime measured from import 🐞 Bug ✓ Correctness

Description

The health endpoint computes uptime from a module-level startTime set at import time, which can be
earlier than when the process is actually ready to serve requests and can reset on module reloads,
making the metric less accurate for monitoring.

Code

backend/src/routes/health.ts[R5-16]

+// Store server start time
+const startTime = Date.now();
+
+/**
+ * GET /api/health
+ * Health check endpoint for monitoring and setup verification
+ * Returns server status, uptime, and timestamp
+ */
+router.get('/', (req: Request, res: Response) => {
+  const now = new Date();
+  const uptimeSeconds = Math.floor((Date.now() - startTime) / 1000);
+  

Evidence

startTime is initialized when the module is imported. Since the server imports routes before
calling app.listen(), the uptime includes pre-listen initialization time rather than true process
uptime.

backend/src/routes/health.ts[5-16]
backend/src/index.ts[6-13]
backend/src/index.ts[38-40]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The health endpoint's `uptime` is based on a `startTime` captured at module import time, which is not the most accurate representation of actual process uptime.
## Issue Context
Routes are imported near the top of `src/index.ts` before `app.listen()` is invoked, so `startTime` is captured before the server is actually listening.
## Fix Focus Areas
- backend/src/routes/health.ts[5-16]
## Suggested fix
- Replace the `startTime`/`Date.now()` delta calculation with `Math.floor(process.uptime())`.
- Remove the module-level `startTime` constant to avoid unnecessary module initialization side effects.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

ⓘ The new review experience is currently in Beta. Learn more