Monitoring

​

Logging

​

Log Levels

• debug: Detailed information for debugging purposes.
• info: General information about the system’s operation.
• warn: Potential issues that may require attention.
• error: Errors that occur during the operation of the system.
• fatal: Critical errors that cause the system to crash.

​

Log Format

• level: The log level (e.g., info, error).
• time: Timestamp of the log entry in milliseconds since epoch.
• pid: Process ID of the application.
• hostname: Hostname of the server where the log was generated.
• requestId: Unique identifier for the request (if applicable).
• userId: Unique identifier for the user (if applicable).
• msg: The log message.
• stack: Stack trace (if applicable).
• data: Additional data related to the log entry.

​

Example Log Entry

{
  "hostname": "server-1",
  "level": 30,
  "msg": "User logged in successfully",
  "pid": 12345,
  "requestId": "abc-123",
  "time": 1710000000000,
  "userId": "user-789"
}

​

Configuring Log Levels

LOG_LEVEL=debug

​

AccessDocker Container Logs

# One-Click setup
cd formbricks
docker compose logs

# Standard Docker commands
docker logs <container-name>
docker logs -f <container-name> # Follow logs

​

Access Kubernetes Pod Logs

kubectl logs <pod-name> -n <namespace>
kubectl logs -f <pod-name> -n <namespace> # Follow logs

​

Log Forwarding

• ELK Stack (Elasticsearch, Logstash, Kibana)
• Fluentd/Fluent Bit
• Datadog
• Splunk
• CloudWatch Logs (AWS)

​

OpenTelemetry Integration

1. Next.js OpenTelemetry - For tracing and APM integration
2. Prometheus Integration - For metrics collection and monitoring

​

Next.js OpenTelemetry for Tracing

OTEL_ENABLED=true
OTEL_ENDPOINT=<your-collector-endpoint> # e.g., http://localhost:4318/v1/traces for OTLP HTTP
OTEL_SERVICE_NAME=formbricks
NEXT_OTEL_VERBOSE=1 # Optional: enables detailed tracing

​

Default Next.js Instrumentation

• HTTP requests and responses
• Route rendering
• API route execution
• Server-side operations
• Database queries
• External API calls

​

Supported Backends for Tracing

Tracing Backends

• Jaeger
• Zipkin
• Tempo

APM & Full-Stack Observability Platforms

• New Relic
• Datadog
• Dynatrace
• Azure Monitor
• AWS X-Ray
• Google Cloud Trace

​

Prometheus Integration

​

Configuration

PROMETHEUS_ENABLED=1
PROMETHEUS_EXPORTER_PORT=9464  # Optional, defaults to 9464

​

Available Metrics

• Host Metrics:
  • CPU usage (user, system, idle)
  • Memory usage (used, free, cached)
  • Disk I/O (reads, writes)
  • Network I/O (bytes in/out, packets in/out)
• HTTP Metrics:
  • Request counts
  • Request durations
  • Error rates
• Runtime Metrics:
  • Garbage collection frequency and duration
  • Event loop lag
  • Heap statistics (size, used, available)
• v3 Responses API Metrics — the two counters and the two unresolved counters below are exported under exactly these series names through both the Prometheus exporter and an OTLP collector. The two histograms are metric families: querying the family name returns nothing, and their queryable series are the _bucket, _sum and _count suffixes.
  • formbricks_api_v3_responses_reads_total — one count per list, count or get, at the route boundary, so a 401, 429 or 400 counts too. Attributes: operation, via (ui, api, mcp), status_class, and filters (the sorted filter keys the caller used, never their values).
  • formbricks_api_v3_responses_read_duration_seconds (histogram family) — wall-clock seconds per read, by operation, via and status_class. Series: formbricks_api_v3_responses_read_duration_seconds_bucket, ..._sum, ..._count. For example, the p95 per operation: histogram_quantile(0.95, sum by (le, operation) (rate(formbricks_api_v3_responses_read_duration_seconds_bucket[5m]))).
  • formbricks_api_v3_responses_page_surveys (histogram family) — how many distinct surveys one list page spans, i.e. the size of its single survey query. Series: formbricks_api_v3_responses_page_surveys_bucket, ..._sum, ..._count. The first bucket boundary is 0.5, so formbricks_api_v3_responses_page_surveys_bucket{le="0.5"} counts empty pages and is distinguishable from one-survey pages.
  • formbricks_api_v3_responses_unresolved_responses_total and formbricks_api_v3_responses_unresolved_entries_total — responses served with a non-empty unresolved[], and its entries by reason. These count every read, so a client polling one unchanged response raises them without any survey edit, and valueShapeMismatch can be legacy malformed data rather than a definition change. Read unresolved_responses_total over reads_total by operation as unresolved responses served per read (a list page can carry several, so for list this can exceed 1; for get it is the share of affected reads), and use unresolved_entries_total grouped by reason for the breakdown, rather than a rising raw count.

​

Collecting Metrics

scrape_configs:
  - job_name: "formbricks"
    static_configs:
      - targets: ["your-formbricks-host:9464"]

​

Resource Attributes

• Environment variables
• Process information
• Host information

​

Health Checks

GET /health

​

AuthZed and SpiceDB