Skip to main content

Health Check Endpoint

Sunschool includes a built-in health check endpoint for monitoring and load balancer integration. From server/auth.ts:

Test Health Endpoint

Railway Health Checks

From ENGINEERING.md:
Health check at /api/healthcheck (60s timeout, restart on failure, max 3 retries)
Railway configuration in railway.json:
Health check behavior:
  • Railway pings /api/healthcheck every 30 seconds
  • 60-second timeout for response
  • If 3 consecutive failures, container restarts
  • Zero-downtime during health check failures

Custom Health Checks

Extend the health check with additional diagnostics:

Logging

Server Logs

Sunschool uses console.log for application logging:

Log Levels

Structured Logging

Not implemented by default. Add structured logging for production monitoring.
Recommended: Winston

Railway Logs

Access logs via Railway CLI:
Log retention:
  • Railway Free: 7 days
  • Railway Pro: 30 days

Error Tracking

Server Errors

From server/middleware/auth.ts:

Error Response Format

Production (NODE_ENV=production):
Development:

Sentry Integration

Recommended for production. Track errors with context and stack traces.

Performance Monitoring

Database Connection Pooling

From server/db.ts:
Monitor pool stats:

Response Times

Track endpoint performance:

Memory Usage

Application Metrics

User Activity

From server/services/activity-service.ts (if implemented):

Lesson Generation Metrics

Alerting

Railway Alerts

Configure alerts in Railway dashboard:
  • Health check failures - Email/Slack on 3+ consecutive failures
  • High memory usage - Alert when > 90% of allocated memory
  • Deployment failures - Notify on failed builds
  • Database connection issues - Alert on connection pool exhaustion

Custom Alerts

Email on critical errors:

Slack Integration

Monitoring Dashboard

Full-featured monitoring stack:
Metrics:
  • Request rates and latencies
  • Database connection pool
  • Memory and CPU usage
  • Custom business metrics

Custom Metrics Endpoint

Troubleshooting with Logs

Common Log Patterns

Log pattern:
Diagnosis: Migration partially applied or run twice.Fix: Check drizzle_migrations table, manually reconcile schema.
Log pattern:
Diagnosis: PostgreSQL not running or wrong DATABASE_URL.Fix: Verify database status and connection string.
Log pattern:
Diagnosis: Bittensor unavailable, automatic fallback working.Action: Monitor fallback frequency, consider disabling Bittensor if unreliable.
Log pattern:
Diagnosis: Memory leak or insufficient memory allocation.Fix: Increase memory limit (NODE_OPTIONS=--max-old-space-size=2048) or fix leak.

Best Practices

1

Enable Health Checks

Configure load balancer or orchestrator to poll /api/healthcheck
2

Structured Logging

Use Winston or Pino for JSON logs with context
3

Error Tracking

Integrate Sentry for production error monitoring
4

Performance Metrics

Track response times, database queries, AI generation duration
5

Alerting

Set up alerts for critical errors, health check failures, high resource usage
6

Log Retention

Archive logs for compliance (30+ days recommended)

Next Steps

Troubleshooting

Debug common issues with logs and metrics

Security

Secure monitoring endpoints and log sensitive data