Getting Temporal Cloud Metrics into SigNoz

This guide shows how to collect Temporal Cloud metrics in SigNoz. You run an OpenTelemetry Collector in your infrastructure, configure it to scrape the Temporal Cloud OpenMetrics endpoint, and forward the metrics to SigNoz via OTLP.

Prerequisites

A Temporal Cloud account with metrics access enabled
An OpenTelemetry Collector installed in your infrastructure
An instance of SigNoz (either Cloud or Self-Hosted)

Most steps are identical. To adapt this guide, update the endpoint and remove the ingestion key header as shown in Cloud → Self-Hosted.

Setup

Step 1: Create a Temporal API key

Create a service account with the Metrics Read-Only role in the Temporal Cloud UI, then generate an API key for that service account. Full instructions are in the Temporal API key guide.

Verify the key works before proceeding:

curl -H "Authorization: Bearer <TEMPORAL_API_KEY>" https://metrics.temporal.io/v1/metrics

Replace <TEMPORAL_API_KEY> with the key you generated. A successful response returns a text stream of Prometheus metric lines.

Step 2: Configure the OpenTelemetry Collector

Choose the setup that matches your environment:

Add the prometheus receiver and SigNoz otlp exporter to your otel-collector-config.yaml. If your collector already has other receivers, append the prometheus block and add it to the pipeline — do not replace your existing config.

otel-collector-config.yaml

receivers:
  prometheus:
    config:
      scrape_configs:
        - job_name: temporal-cloud
          static_configs:
            - targets:
                - 'metrics.temporal.io'
          scheme: https
          metrics_path: /v1/metrics
          scrape_interval: 60s
          honor_timestamps: true
          authorization:
            type: Bearer
            credentials: '<TEMPORAL_API_KEY>'

processors:
  batch:

exporters:
  otlp:
    endpoint: "ingest.<region>.signoz.cloud:443"
    tls:
      insecure: false
    headers:
      "signoz-ingestion-key": "<SIGNOZ_INGESTION_KEY>"

service:
  pipelines:
    metrics:
      receivers: [prometheus]
      processors: [batch]
      exporters: [otlp]

Replace these placeholders:

<TEMPORAL_API_KEY>: the API key you created in Step 1
<region>: your SigNoz Cloud region
<SIGNOZ_INGESTION_KEY>: your SigNoz ingestion key

The credentials field inlines the API key directly in the config file. Anyone with read access to this file can extract the key. For production deployments, consider using credentials_file with a path to a file containing the key (as shown in the Kubernetes tab), or restrict file permissions to the collector's service account.

Restart the collector to apply the config:

./otelcol-contrib --config ./otel-collector-config.yaml

On Kubernetes, store your API key as a Secret and mount it into the collector — do not inline credentials in ConfigMaps.

1. Create Secrets for your API keys

# Temporal Cloud API key
kubectl create secret generic tcloud-api-key --from-literal=token=<TEMPORAL_API_KEY>

# SigNoz ingestion key
kubectl create secret generic signoz-secret --from-literal=SIGNOZ_API_KEY=<SIGNOZ_INGESTION_KEY>

Replace <TEMPORAL_API_KEY> with your Temporal API key and <SIGNOZ_INGESTION_KEY> with your SigNoz ingestion key.

2. Deploy the collector

Apply the manifest below. Before applying, replace <region> in the SIGNOZ_OTLP_ENDPOINT env var with your SigNoz Cloud region.

collector.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: collector-config
  labels:
    app.kubernetes.io/name: collector-config
data:
  collector-config: |
    receivers:
      prometheus:
        config:
          scrape_configs:
            - job_name: temporal-cloud
              static_configs:
                - targets:
                    - "metrics.temporal.io"
              scheme: https
              metrics_path: /v1/metrics
              scrape_interval: 60s
              honor_timestamps: true
              authorization:
                type: Bearer
                credentials_file: /etc/tcloud-api-key/token

    processors:
      batch:

    exporters:
      otlp:
        endpoint: ${SIGNOZ_OTLP_ENDPOINT}
        tls:
          insecure: false
        headers:
          "signoz-ingestion-key": "${SIGNOZ_API_KEY}"

    service:
      pipelines:
        metrics:
          receivers: [prometheus]
          processors: [batch]
          exporters: [otlp]
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: otel-collector
  labels:
    app.kubernetes.io/name: otel-collector
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: otel-collector
  template:
    metadata:
      labels:
        app.kubernetes.io/name: otel-collector
    spec:
      containers:
        - name: collector
          image: otel/opentelemetry-collector-contrib:0.148.0
          env:
            - name: SIGNOZ_OTLP_ENDPOINT
              value: "ingest.<region>.signoz.cloud:443"
            - name: SIGNOZ_API_KEY
              valueFrom:
                secretKeyRef:
                  name: signoz-secret
                  key: SIGNOZ_API_KEY
          volumeMounts:
            - name: collector-config-vol
              mountPath: /etc/otelcol-contrib
            - name: tcloud-api-key
              mountPath: /etc/tcloud-api-key
              readOnly: true
      volumes:
        - name: tcloud-api-key
          secret:
            secretName: tcloud-api-key
        - name: collector-config-vol
          configMap:
            name: collector-config
            items:
              - key: collector-config
                path: config.yaml

3. Apply the manifest

kubectl apply -f collector.yaml

4. Verify the collector is running

kubectl get pods -l app.kubernetes.io/name=otel-collector
kubectl logs -l app.kubernetes.io/name=otel-collector

The logs should show Everything is ready. Begin running and processing data. with no errors from prometheusreceiver.

Step 3: Tune what is scraped (optional)

Query parameters on metrics_path control which series Temporal returns.

Reduce cardinality

If you have many Temporal namespaces, filter what is scraped:

metrics_path: '/v1/metrics?namespaces=<your-namespace>'

You can also filter by metric name: ?metrics=temporal_cloud_v1_workflow_success_count. See high-cardinality management in the Temporal docs for details.

Enable the activity type label

temporal_activity_type is an opt-in label that Temporal does not return by default. Request it to break activity metrics down per activity type:

metrics_path: '/v1/metrics?labels=temporal_activity_type'

This matters most for activity latency. temporal_cloud_v1_activity_start_to_close_latency_* and temporal_cloud_v1_activity_schedule_to_close_latency_* carry no other breakdown dimension, so without this label they report a single namespace-wide percentile and the dashboard's activity latency panels show one unlabelled series. temporal_task_queue and temporal_workflow_type are excluded from those metrics because pre-computed percentiles cannot be re-aggregated across extra dimensions.

The label is applied to every activity metric that supports it, so series count grows with the number of distinct activity types. Enable it when you need per-activity latency rather than by default.

Combine parameters with &:

metrics_path: '/v1/metrics?namespaces=<your-namespace>&labels=temporal_activity_type'

Step 4: Import the dashboard

In SigNoz, go to Dashboards → New Dashboard → Import JSON.

Download the dashboard JSON from Temporal Cloud Metrics. The dashboard includes panels for workflow success rate, service request counts, latency percentiles, and worker poll metrics.

Validate

Metrics should appear in SigNoz within 2–3 minutes of the collector starting. To confirm:

Go to Metrics Explorer in SigNoz and search for temporal_cloud_v1_. You should see metrics like temporal_cloud_v1_service_request_count and temporal_cloud_v1_workflow_success_count.
Open the imported dashboard and verify panels are populated.

Temporal Actions Metrics dashboard panel in SigNoz — *Temporal Actions Metrics*

Temporal Worker Poll metrics dashboard panel in SigNoz — *Temporal Worker Poll Metrics*

Temporal Service Requests metrics dashboard panel in SigNoz — *Temporal Service Requests Metrics*

Migrating from the Prometheus query endpoint (v0)

If you were previously using the Temporal Cloud Prometheus query endpoint (v0), note these breaking changes in the v1 OpenMetrics endpoint:

Metric names changed from temporal_cloud_v0_* to temporal_cloud_v1_*
No rate() needed: metrics are pre-computed per-second rates with delta temporality — do not wrap them with rate(), increase(), or irate()
Latency percentiles are now explicit metrics (e.g., temporal_cloud_v1_service_latency_p99) instead of histogram buckets — histogram_quantile() no longer applies
Authentication changed from mTLS certificates to API keys with the global endpoint https://metrics.temporal.io/v1/metrics

See the full migration guide for the complete metric name mapping table.

Troubleshooting

No metrics appear after 3 minutes

Likely cause: invalid API key, misconfigured receiver, or prometheus missing from the pipeline receivers list.
Fix: run the curl command from Step 1 to confirm the key is valid. Check collector logs for errors from prometheusreceiver. Confirm prometheus is listed under receivers in the metrics pipeline.
Verify: metrics with the prefix temporal_cloud_v1_ appear in Metrics Explorer.

Dashboard shows no data after metrics are visible

Likely cause: dashboard queries may reference old v0 metric names if you imported an older dashboard version.
Fix: confirm the dashboard queries use temporal_cloud_v1_* names. Re-download the latest dashboard JSON from the link in Step 4.
Verify: individual metric panels populate in the dashboard.

Activity latency panels show a single unlabelled series

Likely cause: the temporal_activity_type label is not enabled on the scrape. It is opt-in, so activity latency arrives as one namespace-wide percentile with no per-activity breakdown.
Fix: add ?labels=temporal_activity_type to metrics_path as shown in Step 3, then restart the collector.
Verify: curl -H "Authorization: Bearer <TEMPORAL_API_KEY>" 'https://metrics.temporal.io/v1/metrics?labels=temporal_activity_type' returns activity metrics carrying a temporal_activity_type label.

Next Steps

Set up alerts on Temporal metrics such as temporal_cloud_v1_workflow_failed_count
Explore end-to-end tracing with the Temporal Golang OpenTelemetry guide or the Temporal TypeScript OpenTelemetry guide

Get Help

If you need help with the steps in this topic, please reach out to us on SigNoz Community Slack. If you are a SigNoz Cloud user, please use in product chat support located at the bottom right corner of your SigNoz instance or contact us at cloud-support@signoz.io.