> ## Documentation Index
> Fetch the complete documentation index at: https://system.muzemus.online/llms.txt
> Use this file to discover all available pages before exploring further.

# Monitoring and health checks

> Application monitoring, logging, and the health endpoint

MUZE currently has minimal monitoring infrastructure. This is a known gap tracked in [Known limitations](/engineering/known-limitations).

## Current state

| Layer                  | State                 | Where            |
| ---------------------- | --------------------- | ---------------- |
| Uptime monitoring      | None                  | —                |
| Error tracking         | None                  | —                |
| Performance monitoring | None                  | —                |
| Log aggregation        | Application logs only | Render dashboard |
| Database monitoring    | Basic metrics         | Neon dashboard   |

## Application logging

The backend uses NestJS's built-in logger:

```typescript theme={null}
this.logger.log('Order approved: ' + orderId);
this.logger.warn('Rate limit exceeded for client: ' + clientId);
this.logger.error('Failed to send email: ' + error.message);
```

Logs are visible in the Render dashboard but not aggregated or persisted long-term.

## What is monitored today

**Render dashboard:** application logs (stdout/stderr), CPU and memory, request counts and response times, deployment history.

**Neon dashboard:** query performance, connection counts, storage usage, backup status.

## Health check endpoint

```
GET /api/v1/health
```

```json theme={null}
{
  "status": "ok",
  "timestamp": "2026-09-04T12:00:00.000Z",
  "uptime": 86400
}
```

The implementation is a simple controller:

```typescript theme={null}
@Controller('health')
export class HealthController {
  @Get()
  check() {
    return {
      status: 'ok',
      timestamp: new Date().toISOString(),
      uptime: process.uptime(),
    };
  }
}
```

The endpoint only confirms the process is running. It does not yet verify database connectivity, email service availability, or R2 storage.

### Liveness vs readiness

| Check                       | Current state           | Recommended                                                                                         |
| --------------------------- | ----------------------- | --------------------------------------------------------------------------------------------------- |
| Liveness (`/health/live`)   | Combined into `/health` | Separate endpoint confirming the process is running                                                 |
| Readiness (`/health/ready`) | Not implemented         | Separate endpoint confirming dependencies are reachable, so traffic stops when the database is down |

## Using with external monitors

The endpoint can be pointed at by any HTTP monitor:

| Tool         | Configuration                                |
| ------------ | -------------------------------------------- |
| Better Stack | URL monitor on `GET /api/v1/health`          |
| UptimeRobot  | HTTP(s) monitor expecting `200 OK`           |
| Render       | Built-in health check path: `/api/v1/health` |

## Recommended additions

| Tool                        | Purpose                                       |
| --------------------------- | --------------------------------------------- |
| Better Stack or UptimeRobot | Uptime monitoring and alerting                |
| Sentry                      | Error tracking                                |
| Log aggregation             | Persistence beyond Render's \~7-day retention |

The application-level `AuditLog` table is the only permanent activity record today.