Frona exposes a Prometheus-compatible metrics endpoint for monitoring your deployment.

Metrics endpoint

The engine exposes metrics at:

GET /api/metrics

This returns metrics in Prometheus exposition format, ready to be scraped by Prometheus, Grafana Agent, or any compatible collector.

Available metrics

The metrics endpoint provides standard application metrics including:

• HTTP request counts and latencies
• Active connections and sessions
• Task execution counts and durations
• Error rates

Setting up Prometheus

Add the Frona engine as a scrape target in your Prometheus configuration:

scrape_configs:
  - job_name: 'frona'
    scrape_interval: 15s
    static_configs:
      - targets: ['frona-engine:3001']
    metrics_path: '/api/metrics'

Health check endpoints

Frona provides health check endpoints for load balancers, orchestrators, and monitoring tools.

Endpoint	Auth	Description
GET /healthz	No	Kubernetes-style health check. Returns {"status": "ok"} with 200, or {"status": "draining"} with 503 during shutdown.
GET /api/system/info	Yes	Returns system information: version, CPU count, total memory, and sandbox driver.
GET /api/system/version	Yes	Returns the engine version.

Use /healthz for Docker health checks and Kubernetes liveness/readiness probes. It requires no authentication and returns 503 during graceful shutdown, so load balancers stop routing traffic before the server exits.

Docker Compose

services:
  frona:
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3001/healthz"]
      interval: 30s
      timeout: 5s
      retries: 3

Kubernetes

livenessProbe:
  httpGet:
    path: /healthz
    port: 3001
  initialDelaySeconds: 10
  periodSeconds: 30
readinessProbe:
  httpGet:
    path: /healthz
    port: 3001
  periodSeconds: 10

Log monitoring

The engine outputs structured logs to stdout. In Docker Compose, view them with:

# All services
docker compose logs -f

# Just the engine
docker compose logs -f frona

# Last 100 lines
docker compose logs --tail 100 frona

For production, consider forwarding logs to a centralized logging system (ELK, Loki, etc.) using a Docker logging driver.

Key things to watch

• Engine health: is the container running and responding to requests?
• Browserless sessions: are sessions being created and cleaned up properly?
• Disk usage: the database and browser profiles grow over time
• Memory usage: especially when many browser sessions are active
• LLM API errors: provider outages or rate limits affect agent responses