Uptime Monitoring

SMLL can continuously monitor your web services and alert you when they go down.

Enabling uptime checks

Uptime monitoring is available for web services:

Go to your web service's settings
Enable Uptime Monitoring
SMLL begins checking your service's health endpoint at regular intervals

How it works

The uptime checker periodically sends HTTP requests to your service's health check path (default /healthz). If the check fails, you're notified through your configured alert channels.

Checks run from SMLL's monitoring infrastructure, giving you an external perspective on your service's availability — not just internal Kubernetes health.

Status monitoring

The uptime dashboard shows:

Current status — whether each monitored service is up or down
Response time — latency of health check responses
Uptime percentage — availability over the selected time period
Incident history — when services went down and recovered

Check configuration

Setting	Default	Description
Path	`/healthz`	HTTP path to check
Interval	60 seconds	Time between checks
Timeout	10 seconds	Max wait for response
Failure threshold	3	Consecutive failures before alerting

A service is considered down after 3 consecutive failed checks (3 minutes with default settings).

Alerting

Uptime alerts are sent through the same notification channels used for metric alerts. See Alerting for setup details.

Best practices

Use a dedicated health endpoint — create a /healthz or /health route that checks critical dependencies (database connection, required services)
Keep health checks fast — the endpoint should respond in under 1 second
Don't require authentication — health check endpoints should be publicly accessible
Check downstream dependencies — a healthy response should mean the service can actually serve requests

Health Checks — internal Kubernetes health checks
Alerting — configure where notifications are sent
Metrics — resource utilization dashboards