> ## Documentation Index
> Fetch the complete documentation index at: https://docs.heygarth.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Health Check
> Monitor the health of G360's underlying system, database, telemetry pipeline, background workers, and connected API keys.
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
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
Shows detailed PostgreSQL diagnostics.
At the top, four cards summarize the database's condition:
| Card | What it shows |
| -------------------- | -------------------------------------------------------------------------------------------- |
| **Status** | Overall database health — **Healthy** or **Warning** (shown when something needs attention). |
| **DB Size** | Total size of the database (for example, "11 GB"). |
| **Latency** | Current query latency in milliseconds. |
| **Connection Usage** | What percentage of the maximum allowed connections are currently in use. |
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
Shows the health of the OpenTelemetry pipeline that G360 uses to ingest metrics from your connected tools.
Three cards summarize its state:
| Card | What it shows |
| ---------------------- | --------------------------------------------------------------------------------------- |
| **Pipeline Status** | Whether the telemetry pipeline is processing data end-to-end (for example, **Ok**). |
| **Collector Liveness** | Whether the OpenTelemetry collector process itself is running (for example, **Alive**). |
| **Roster Size** | The number of entities (e.g. users/hosts) currently being tracked by the pipeline. |
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
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
Shows the validity of every API key G360 uses to connect to your integrated tools.
Three summary cards show:
| Card | What it shows |
| ----------------------- | ------------------------------------------------------------ |
| **Total Keys** | Total number of API keys configured across all integrations. |
| **✓ Valid** | How many of those keys are currently valid and working. |
| **✗ Invalid / Expired** | How many keys are currently failing authentication. |
The table below lists every key individually:
| Column | What it shows |
| ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Key Name** | The name given to this key/connection, with its response time underneath. |
| **Provider** | Which tool this key connects to (for example, GitHub, GitHub Copilot). |
| **Status** | **✓ Valid** or **✗ Invalid / Expired**. |
| **Details** | For invalid keys, the raw error returned by the provider (for example, a 401 "Bad credentials" response), which helps you diagnose exactly why the key is failing. |
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**.