Start Here

Metrics is in open alpha

Any team can turn on metrics: open Metrics (opens in a new tab) in PostHog and select Enable metrics in the onboarding view. See turn on metrics (opens in a new tab) for the full flow. Setup details, including the ingestion endpoint, may change before general availability.

Send your first metrics

There are three ways to get metrics into PostHog, and all take just a few minutes.

If posthog-js (opens in a new tab) is already running on your site, record metrics directly with the posthog.metrics API. No new packages, no extra authentication:

JavaScript

If you use OpenTelemetry anywhere else (backend services, infrastructure, an existing Collector), point your OTLP metrics exporter at PostHog. No PostHog packages are required:

Terminal

If you run Kubernetes and your pods already expose Prometheus metrics, install the PostHog metrics agent Helm chart to scrape and forward them automatically:

Terminal

<ph_client_api_host> and <ph_project_token> are filled in with your project’s values when you’re logged in. Use your project token (the same one you use for capturing events), not a personal API key (opens in a new tab).

For per-platform setup, including the posthog.metrics API in Node.js (opens in a new tab) and Python (opens in a new tab), see the installation guides (opens in a new tab).

Pick the right metric type

Metrics come in three shapes, and picking the right one determines which aggregations make sense later:

• Counters only go up: requests handled, jobs processed, errors raised. Chart them with rate or increase.
• Gauges go up and down: queue depth, active connections, memory in use. Chart them with avg.
• Histograms record distributions: request durations, payload sizes. Chart them with percentiles like p95.

Give each metric a stable, descriptive name (http.server.duration, jobs.processed.total) and set a service name so metrics from different systems stay easy to tell apart.

Add attributes, carefully

Attributes let you slice a metric by dimension: route, status code, plan, region. Every unique combination of attribute values creates a new series, so attach dimensions with a small, bounded set of values.

Good attributes: route, status, plan, queue. Bad attributes: user IDs, session IDs, request IDs, timestamps. Each of those would create a series per user or per request, which makes charts unreadable and ingestion expensive.

If you need to know what happened for one specific user or request, that’s a job for logs (opens in a new tab) or traces (opens in a new tab), not metrics.

Verify metrics are arriving

Open Metrics in the PostHog sidebar. The Overview tab shows your services, metric names, and active series over the last day, so you can confirm data is landing. In the Viewer tab, pick your metric from the name picker and you should see data points within a minute of sending. The viewer recommends an aggregation based on the metric’s type, so a counter defaults to increase and a gauge to avg.

If nothing shows up, check that the endpoint ends in /i/v1/metrics, that the token starts with phc_, and see the troubleshooting section (opens in a new tab).

Chart what matters

Once data flows, build the views you’ll actually watch:

• Group by an attribute to get one line per value, for example request rate per route or queue depth per worker.
• Filter with key=value chips to focus on one service, environment, or status.
• Watch for the anomaly badge — when the metric moves against its baseline, it shows the change and the label values that drove it.
• Turn on auto-refresh to update the chart every few seconds while you watch a deploy or an incident.

When a chart is worth keeping, save it as an insight or add it to a dashboard — or use New service dashboard to build one insight per metric in a single step.

Query with SQL or ask AI

Every metric lands in the posthog.metrics table, so the SQL tab in the metrics viewer gives you full query access for anything the chart controls don’t cover.

If you use the PostHog MCP server (opens in a new tab), your AI tools can query metrics directly: ask your agent to chart a metric, compare error rates between services, or characterize an anomaly, all without leaving your editor.

For the full tour of the viewer — anomaly detection, pivoting into logs and traces, and dashboards — see Use your metrics (opens in a new tab).

1/6

Send your first metrics RequiredPick the right metric type RequiredAdd attributes, carefully RequiredVerify metrics are arriving RequiredChart what matters RecommendedQuery with SQL or ask AI Optional

Send your first metrics

Required

Still have questions?

Ask PostHog AI

Was this page useful?

HelpfulCould be better