Monitoring

📊 Monitoring

📊 Monitoring

Know when something breaks before your users do.

HridaAI exposes health and model endpoints that make it straightforward to wire up uptime monitoring, model connectivity checks, and end-to-end response testing. Whether you're running a single instance or a multi-node deployment, these checks give you confidence that the service is up, models are reachable, and inference is actually working.

✅ Health Endpoint🔗 Model Connectivity🤖 Deep Health Check🐻 Uptime Kuma📡 OpenTelemetry

Why Monitor?

⚡

Catch outages quickly

A health check that runs every 60 seconds means you know about downtime within a minute, not when a user files a complaint.

🔗

Verify model connectivity

HridaAI can be running fine while your model provider is down. Monitoring the /api/models endpoint catches that gap.

🤖

End-to-end confidence

The deepest check sends a real prompt and validates the response. If that passes, you know the entire pipeline works: API, backend, model provider, and inference.

Key Features

Feature	Description
✅ Health endpoint	Unauthenticated /health check, returns 200 when the service is up
🔗 Model connectivity	Authenticated /api/models check verifies provider connections
🤖 Deep health check	Send a real chat completion and validate the response
🐻 Uptime Kuma recipes	Ready-to-use configurations for each monitoring level

---

Level 1: Basic Health Check

Level 1

Basic Health Check

The /health endpoint is publicly accessible (no authentication required) and returns 200 OK when the service is running.

curl http://your-hrida-ai-instance:8080/health

This verifies web server availability, application initialization, and basic database connectivity.

Uptime Kuma Setup

• Add New Monitor with type HTTP(s)
• URL: http://your-hrida-ai-instance:8080/health
• Interval: 60 seconds
• Retries: 3

---

Level 2: Model Connectivity Check

Level 2

Model Connectivity Check

The /api/models endpoint requires authentication and confirms that HridaAI can reach your model providers and list available models.

curl -H "Authorization: Bearer YOUR_API_KEY" \
  http://your-hrida-ai-instance:8080/api/models

You'll need an API key. See API Keys for setup instructions.

💡 Dedicated Monitoring Account

Create a non-admin user (e.g., monitoring-bot), generate an API key from that account, and use it for all monitoring requests. This limits blast radius if the key is ever compromised.

Uptime Kuma Setup

• Monitor Type: HTTP(s) - JSON Query
• URL: http://your-hrida-ai-instance:8080/api/models
• Method: GET
• Header: Authorization: Bearer YOUR_API_KEY
• JSON Query: $count(data[*])>0
• Expected Value: true
• Interval: 300 seconds (5 minutes)

Advanced JSONata Queries

Goal	Query
At least one Ollama model	$count(data[owned_by='ollama'])>0
Specific model exists	$exists(data[id='gpt-4o'])
Multiple models exist	$count(data[id in ['gpt-4o', 'gpt-4o-mini']]) = 2

Test queries at jsonata.org with a sample API response.

---

Level 3: Deep Health Check

Level 3

Deep Health Check

Send a real chat completion to verify the entire inference pipeline end-to-end.

curl -X POST http://your-hrida-ai-instance:8080/api/chat/completions \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "messages": [{"role": "user", "content": "Respond with the word HEALTHY"}],
    "model": "llama3.1",
    "temperature": 0
  }'

A successful response returns 200 OK with a chat completion containing "HEALTHY". This catches model loading failures, backend processing errors, and provider-side issues that Levels 1 and 2 would miss.

ℹ️ Info

Setting up Level 3 in Uptime Kuma requires an HTTP(s) monitor with a POST body, authentication headers, and a JSON query to validate the response. See Uptime Kuma docs for POST monitor configuration.

---

Next Steps

📡

OpenTelemetry

Distributed tracing, metrics, and logs with Grafana, Prometheus, Jaeger, and more

🔑

API Keys

Full guide on enabling and generating API keys for programmatic access