ghp exposes Prometheus metrics and structured access logs for observability.

Prometheus Metrics

When metrics are enabled (the default), ghp runs a dedicated metrics server on a separate port. This keeps metrics traffic isolated from the main proxy.

metrics:
  enabled: true
  listen: ":9136"

Scrape the metrics endpoint at http(s)://<ghp-server>:9136/metrics (HTTPS when ghp runs with TLS enabled, HTTP otherwise).

Available Metrics

HTTP Request Metrics

The backend label distinguishes traffic by virtualhost: api.github.com, github.com, copilot, or management.

Proxy Metrics

The type label distinguishes API traffic from git smart-HTTP traffic (e.g. type="git" for git operations proxied via the github.com backend). The decision pipeline metric breaks down the overhead ghp adds to each request into individually timed stages so you can identify where latency originates. The stages are:

Git Cache Metrics

ghp_cache_fetch_total result values:

ghp_cache_request_total result values:

Identifying cache candidates

The ghp_cache_request_total metric includes owner and repo labels, enabling per-repository analysis. Use it to identify repositories that would benefit from caching:

# Top 10 uncached repos by request volume — candidates for adding to cache
topk(10, sum by (owner, repo) (ghp_cache_request_total{result="nocache"}))

# Repos configured but disabled — consider re-enabling
sum by (owner, repo) (ghp_cache_request_total{result="bypass"})

# Cache hit rate per repo — verify caching is effective
sum by (owner, repo) (ghp_cache_request_total{result="hit"})
/ sum by (owner, repo) (ghp_cache_request_total)

# Repos with high miss rates — may need cache warming or service token
sum by (owner, repo) (ghp_cache_request_total{result="miss"})
/ sum by (owner, repo) (ghp_cache_request_total{result=~"hit|miss"})

See Git Cache for configuration details.

Token Metrics

GitHub Rate Limit Metrics

Security Metrics

Release Controls Metrics

The result label on the HEAD check counter has three values:

When redirect_head_check is enabled, each HEAD request is also timed in the decision pipeline histogram (ghp_proxy_decision_duration_seconds) under the redirect_head_check stage. This lets you monitor how much latency the availability probe adds to redirected release downloads.

See Release Download Controls for configuration details.

Access Logs

ghp writes structured JSON access logs for every request across all four virtualhosts. Each log entry typically includes:

• HTTP method, host, URI/path, and status code
• Request duration
• Backend identifier (same values as the backend label used in metrics)
• User identifier (GitHub username when available)
• Selected request and response headers (sensitive values such as Authorization and Set-Cookie are redacted)

Configure logging output and level:

logging:
  output: "stdout"         # "stdout" or "file"
  level: "info"            # "debug", "info", "warn", "error"
  file:
    path: "/var/log/ghp/ghp.log"

Server Response Header

Every response from ghp includes a Server: GitHub Proxy <version> header. This makes it easy to verify that traffic is flowing through ghp rather than directly to GitHub, and to identify which version of ghp is running.

Health Check

The /auth/status endpoint on the management host returns the current authentication status. It requires authentication and returns HTTP 401 when no valid session cookie is present, and HTTP 200 only when the user is authenticated. This makes it unsuitable for unauthenticated liveness checks that expect a 2xx response.

For basic unauthenticated liveness checks, use the documentation endpoint which is always accessible without authentication:

curl -s https://ghp.example.com/docs/

To verify both service health and authentication, use /auth/status with an authenticated session and expect HTTP 200 on success:

curl -s https://ghp.example.com/auth/status