Skip to main content
The Health Check page gives administrators a live view into the health of G360’s own infrastructure — its services, database, telemetry pipeline, background workers, and the API keys powering your integrations. This page lives under Administration → Health Check in the left sidebar. Five sub-tabs organize this view: Application Services, Database, OTel Health, Celery & Redis, and Keys. Each has its own Refresh button to pull the latest status on demand.

​
Application Services

Health Check - Application Services
Shows the liveness of G360’s core services and their connectivity to one another.
  • Overall Status — a single healthy/unhealthy indicator for the system as a whole (for example, Healthy).
  • Environment — which environment this status reflects (for example, Dev).
The table below lists each core service, its connectivity Status (for example, ✓ Connected or ✓ Ok), and any relevant Details (for example, “1 worker active” for Celery).

​
Database

Health Check - Database
Shows detailed PostgreSQL diagnostics. At the top, four cards summarize the database’s condition: Below that:
  • Version — the PostgreSQL version and host platform.
  • Connections — Active connections, connections Idle in Transaction, Max Allowed, and overall Utilization.
  • Performance — Cache Hit Rate, Long Running Queries, Lock Waits, Temp Files, and Temp Disk Usage.
  • Errors — Deadlocks and Rollback Ratio.
  • Warnings — any active warnings (for example, high temp file or temp disk usage), each with a short explanation of what’s elevated.
A high Temp Files or Temp Disk Usage figure usually means queries are spilling to disk instead of completing in memory — worth investigating if you see a Warning status here.

​
OTel Health

Health Check - OTel Health
Shows the health of the OpenTelemetry pipeline that G360 uses to ingest metrics from your connected tools. Three cards summarize its state: Below that:
  • Collector — Liveness, Uptime, and the timestamp the collector has been Up Since.
  • Pipeline — Pipeline Status, when it was Configured At, the Last Data Received timestamp, the Last Request Date, Days Since Last Data, and whether an Ingest Token is Set.
As explained in the note on this tab: liveness simply means the collector process is alive (its port is open), while pipeline_status confirms data is actually flowing end-to-end — so check pipeline status, not just liveness, to confirm telemetry is really working.

​
Celery & Redis

Health Check - Celery & Redis
Shows the health of the background job queue (Celery) and its cache/broker (Redis), along with when it was last checked. A circular Health score (for example, “100”) summarizes overall condition, alongside a component count (for example, “4/4 components healthy”). Four component cards break this down individually:
  • Redis — the broker/cache store, with its response time.
  • Celery Broker — the connection to Redis, with its response time.
  • Celery Workers — how many workers are online, with response time (flagged as slow if it exceeds normal thresholds).
  • Result Backend — task result storage, with its response time.
Further down:
  • Response Latency — a bar chart comparing the latest response time per component (a red bar highlights a slow component, like Celery Workers here).
  • Queue Depth — pending tasks per queue (shows “No pending tasks” when the queue is empty).
  • Celery Workers table — each active worker’s name, online Status, worker Pool type, Concurrency, Active Tasks, and total Processed task count.
  • Redis — version, uptime, connected clients, used memory, and key count.
  • Celery Broker & Result Backend — the Broker URL, Result Backend URL, Active Queues, and Pending Tasks.
At the bottom, a Raw API Response section can be expanded to view (and Copy) the underlying raw health-check response — useful if you need to share exact diagnostic data with support.

​
Keys

Health Check - Keys
Shows the validity of every API key G360 uses to connect to your integrated tools. Three summary cards show: The table below lists every key individually:
A large number of Invalid / Expired keys, especially ones sharing the same error, usually points to a token that’s expired or been revoked at the source (e.g. GitHub) rather than an issue with G360 itself — regenerate the token in the provider and reconnect it under Integration.