Temporal Cloud observability in Elastic: 50+ metrics, zero collectors
Elastic scrapes metrics.temporal.io, so the workflow that has been stuck in Running for an hour turns out to be a task queue nobody is polling, and you find that out before you open a single worker log.
Elastic speaks OpenTelemetry natively. Send traces, logs, and metrics over OTLP straight into Elasticsearch, no proprietary agents required. See how it fits together, try it for free in the cloud, or run it locally.
Temporal Cloud observability in Elastic takes an API key and nothing else. Elastic scrapes metrics.temporal.io itself, so there is no agent on your workers and no collector to size. The Temporal OpenTelemetry Integration pulls in more than fifty OpenMetrics series, and once data lands in the data stream, a dashboard, seven alert templates and three SLO templates install themselves. Elastic is listed on Temporal's own observability integrations page.
A Temporal workflow can sit in Running for a long time and still be stuck. Maybe the worker that should poll its task queue is gone. Or the namespace is burning through its action budget, or an activity is timing out on StartToClose while the frontend latency graph still looks fine. You run the workers, Temporal runs the service, and the failure is usually in the gap between them. You only see it if the Cloud metrics feed sits somewhere you can query next to the rest of your stack.
What Temporal Cloud metrics does Elastic collect?
Temporal Cloud publishes more than fifty OpenMetrics series, aggregated in one-minute windows. Each scrape returns only the most recently completed minute, so Elastic has to keep the history. Names stay as Temporal published them, under metrics.* on metrics-temporal.cloud_metrics.otel-*.
The useful split is not "infrastructure vs application." It is:
| If you are asking | Start with |
|---|---|
| Are workflows finishing? | Success, fail, and timeout counts, plus schedule-to-close latency |
| Are activities dying on the worker? | Activity fail and timeout rates, including heartbeat vs StartToClose |
| Is work waiting on an empty fleet? | no_poller_tasks_count, poll success vs poll timeout, backlog size |
| Is the Cloud frontend itself slow? | Service request count, error count, p99 latency by operation |
| Are you about to get throttled? | Action, operation, and poller limits versus consumption |
| Is a multi-region namespace drifting? | Replication lag percentiles |
The full metric catalog is in Temporal's metrics reference. The integration does not rename it.
How to connect Temporal Cloud metrics to Elastic
- In Temporal Cloud, go to Settings → Service Accounts and create a Service Account with the Metrics Read-Only role.
- Generate an API key on that account and store it. It is shown once.
- Confirm the endpoint answers. You should see
# TYPE temporal_cloud_v1_...lines, not a browser page. Opening the URL without a bearer token returnsJwt is missing.
curl -H "Authorization: Bearer <API_KEY>" https://metrics.temporal.io/v1/metrics
- In Kibana, go to Management → Integrations, search for Temporal (OpenTelemetry), and add it.
- Leave the endpoint at
metrics.temporal.io:443and the path at/v1/metrics. - Paste the API key.
Verify in Discover with data_stream.dataset: "temporal.cloud_metrics.otel". The first documents show up a few minutes after the first completed one-minute window. Once that data is in metrics-temporal.cloud_metrics.otel-*, the Temporal OpenTelemetry Assets package installs the dashboard, alert templates, and SLO templates automatically. You do not add those by hand.
For field-level detail, use the Temporal OpenTelemetry Integration docs.
What the Temporal Cloud Metrics dashboard shows
The assets package installs one dashboard: [Temporal OTel] Cloud Metrics. It is a golden-signals board, not four product-area tabs.
Is the Temporal Cloud frontend keeping up?
Overview and latency tiles show request volume and p99 by namespace and operation. A spike here hits every StartWorkflow, Signal, and poll, not just one task queue.
Are workflows completing or timing out?
The errors view breaks workflow and activity terminals into success, failure, and timeout. Workflow timeouts mean the execution ran out of wall-clock time. Activity StartToClose timeouts mean the worker exceeded its attempt budget. Heartbeat timeouts usually mean the process died mid-run.
Are you out of workers or out of action quota?
Saturation and capacity cover backlog depth, poller presence, open workflow count, and action-limit headroom. A queue with tasks and zero pollers is a different incident from a namespace at 80% of its action limit. Both show up here before workflows start timing out.
Temporal Cloud alert templates and what each rule catches
The assets package ships rule templates for the ways Temporal Cloud actually fails. They group more usefully by cause than by metric prefix.
Worker and task queue alerts
- No pollers on a task queue: Tasks are being dispatched and nobody is listening. New work for that queue is stuck immediately.
- Task queue backlog growing: Arrivals are faster than claims. Left alone, this becomes workflow timeouts.
- Activity task timeout rate elevated: StartToClose vs heartbeat tells you slow dependencies versus a crashed worker.
- High activity task failure rate: Retries are burning. Persistent rates exhaust the retry budget and fail the workflow.
Namespace capacity alerts
- Namespace approaching action rate limit: 80% of provisioned actions. Past the limit, Temporal Cloud throttles new events.
- Open workflow count anomaly: In-flight executions grow without matching throughput. Something is not completing.
Workflow timeout alerts
- Workflow timeout rate elevated: Executions hit
workflowExecutionTimeout. That is a clock problem, not a retry problem.
Three Temporal Cloud SLO templates and their thresholds
All three templates use a rolling 30-day window.
- Service latency p99 below 100ms, 99%: The Cloud frontend stays fast enough that Start, Signal, and poll do not drag. Grouped by namespace and operation.
- Task queue backlog below threshold, 99%: Pending tasks stay under 1,000 per five-minute slice, per namespace and queue.
- Workflow success rate 99.5%: Most one-minute slices keep successful completions above 95% of terminal outcomes (success, failure, timeout), by namespace.
Tune the backlog and success-rate numbers to your own traffic before you treat them as a contract.
Start using Temporal Cloud observability in Elastic
If you have Temporal Cloud and already use Elastic Cloud, you can start today. Elastic scrapes Temporal Cloud's OpenMetrics endpoint for you. There is no agent on your workers and no collector to run.
The integration requires Elastic 9.5 or later, on Elastic Cloud Serverless or Elastic Cloud Hosted. Create the Metrics Read-Only key, then add Temporal (OpenTelemetry) from Management → Integrations in Kibana, or follow the Temporal OpenTelemetry Integration docs.
How helpful was this content?
Related Content

Telemetry Policy: change OpenTelemetry sampling and log levels at runtime, no restart

Monitor Supabase in Elastic: dashboards, alert templates, SLO templates, and zero agents

AI root cause analysis in Elastic Agent Builder that cites its evidence

