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)
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.
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.
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: Reduce scrape cardinality (optional)
If you have many Temporal namespaces, use query parameters on metrics_path to 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.
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 liketemporal_cloud_v1_service_request_countandtemporal_cloud_v1_workflow_success_count. - Open the imported dashboard and verify panels are populated.
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_*totemporal_cloud_v1_* - No
rate()needed: metrics are pre-computed per-second rates with delta temporality — do not wrap them withrate(),increase(), orirate() - 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
prometheusmissing from the pipeline receivers list. - Fix: run the
curlcommand from Step 1 to confirm the key is valid. Check collector logs for errors fromprometheusreceiver. Confirmprometheusis listed underreceiversin 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.
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.