How to monitor Temporal with Prometheus and Grafana before workflows stall
Operators usually learn about a Temporal problem when a business process stops moving. A workflow waiting on a task queue rarely fails loudly, because the work simply sits until a worker picks it up. When task queues back up or workers fail, the first sign is often a customer complaint or a missed batch window. This section puts signals in front of the team first: backlog growth, task queue latency and worker availability, watched continuously so someone can act while the queue is still draining. Set these signals up before the first production workload goes live, not after the first incident.
The supported method is Prometheus scraping HTTP metrics endpoints that the Temporal services and your workers expose. Prometheus pulls samples from each target, found through service discovery or static configuration, and stores them in its local time series database. Grafana reads Prometheus as a data source and draws the dashboards that operators use during a shift. Alertmanager receives the alerts that Prometheus rules raise and routes them to the right owners, with grouping, silences and inhibition to cut noise. Each component has a distinct job, so an outage in one layer should not blind the others.
Confirm the exact endpoints, ports and metric names in the Temporal documentation for your server version before you write any scrape configuration or alert rule. This page does not list them, and names can change between releases, so check the release notes for the version you run. Build a short inventory that records, for each Temporal service and each worker role, the endpoint, the scrape interval you chose and the team that owns the alert. Treat that inventory as a controlled document, and review it again each time you plan a server upgrade.
Several decisions need an owner early. Prometheus keeps data locally for 15 days by default, and its local storage is not clustered or replicated, so decide whether you need remote write to long-term storage for trend analysis after an incident. Run Alertmanager as a cluster and point Prometheus at every Alertmanager instance. If you run more than one Grafana server, plan the alerting configuration so the same notification does not reach on-call staff twice. Define data sources and dashboards in provisioning files so the monitoring setup can be reviewed, versioned and rebuilt.
What you need in place before scraping Temporal
Scraping Temporal works only when the server, the monitoring stack and the network path are in a known state before any dashboard is built. Each card names a version line to target, a dependency to configure, or a check to make in your environment. Confirm every item against your own deployment so the scrape configuration you write matches what is actually running.
Temporal Server on a supported line
Confirm that your Temporal Server is v1.32.1 or a patch on the v1.31.4 or v1.30.8 lines. Metric names and labels can change between minor lines, so check them against the version you actually operate before you write alert rules. Upgrades should move one minor version at a time, moving first to the latest patch of the current minor. Where release notes call for it, apply schema upgrades before the server upgrade, and record the version in your monitoring runbook.
Prometheus on LTS 3.13 or latest minor
Choose Prometheus 3.13, the current long-term support line, which receives bug fixes until July 31, 2027, or the latest minor release. Minor releases generally stop receiving bug fixes about six weeks after they ship, so a minor line needs a regular upgrade cadence. The LTS line suits teams that want a longer maintenance window for scrape and alert rules. Record the exact version you deploy, and test scrape jobs and recording rules against it before each change.
Grafana on a supported minor release
Run a Grafana minor from the 13.x line that is still in its support window, such as 13.2 with the patch releases published in October 2026. Each minor release is supported for nine months, and the last minor of a major version for 15 months, so check the end-of-support date before you standardize on a minor. Patch releases arrive at least monthly, and your change process should include them so dashboards and alert behavior stay current.
Production-grade Grafana database
Grafana stores its configuration in SQLite by default, and the installation guidance states that SQLite does not scale for production. Provision MySQL 8.0 or later, or PostgreSQL 12 or later, for configuration and state. Size the database for your user count and dashboard volume, back it up on a schedule, and test a restore before go-live. If you plan high availability, this database becomes the shared state for two or more Grafana servers behind a load balancer.
Network path from Prometheus to metrics
Prometheus must reach every Temporal metrics endpoint it scrapes. Temporal services should run on hosts that are not reachable from the public internet, with network access restricted to trusted internal networks. Map each source and destination, open only the scrape port you configure, and confirm that Prometheus can also reach its Alertmanager instances. Document the path in your network diagram so a firewall change does not silently stop scraping.
Helm chart 0.73.1 or later on Kubernetes
If Temporal runs on Kubernetes, use Helm chart version 0.73.1 or later. Chart versions below 0.73.1 do not work with server images 1.30 and later, so an older chart will fail once you move to a supported server line. Check the chart version and the server image tag together before each upgrade. Confirm which pods expose metrics, so your scrape jobs cover every Temporal service rather than only the frontend.
How Prometheus pulls Temporal metrics and what Grafana reads
Prometheus collects Temporal metrics by pulling them. On a fixed schedule it sends HTTP requests to each target and reads the metrics that target exposes. It learns which targets to scrape either from service discovery, which in Kubernetes means watching pods and services for the Temporal services, or from a static list in its configuration. Before you build anything, confirm which Temporal services expose a metrics endpoint in your chosen deployment method and which port they use, then check that the Prometheus pods or hosts can reach each one. Every scraped sample is written to Prometheus's local time series database, so a scrape failure and a storage problem look different and should be troubleshot separately. The pull model suits long-running server and worker processes, but confirm with your deployment design which components, if any, need a different path.
Prometheus writes samples into two-hour blocks backed by a write-ahead log, and by default it keeps data for 15 days. You can set retention by time or by size. Local storage is not clustered or replicated. Two Prometheus servers scraping the same Temporal targets hold two independent copies of the data, and losing a host without a backup means losing its history. Size the disk against your retention setting, and treat the Prometheus host like any single-node database with backups and tested restores. Remote write is the documented route to longer-term storage: Prometheus sends samples to an external system, which becomes another service to deploy, secure, size and monitor. Decide early whether 15 days covers the questions your operators ask, such as how a backlog trended over the last month.
Grafana does not collect or store Temporal metrics. It reads them by sending PromQL queries to Prometheus through a data source, and each panel on a dashboard is one or more of those queries. Dashboard quality therefore depends on the metric names and label values your Temporal version exposes, so test each query against a live Prometheus before you build panels around it. Grafana provisioning can define the Prometheus data source and dashboards in YAML or JSON files loaded at startup, which keeps the setup reviewable and repeatable across environments. Grafana's own database stores users, dashboards and settings. For production and high availability, Grafana needs MySQL or PostgreSQL, and that database is separate from the metrics store, so it needs its own backup plan.
Prometheus evaluates alert rules and sends firing alerts to Alertmanager, which groups related alerts, applies inhibition and silences, and routes notifications to receivers. Alert rules for Temporal conditions, such as a growing task backlog or rising workflow failures, are defined in Prometheus. Grafana can also raise alerts, so decide which tool owns each alert to avoid duplicate notifications. Prometheus should list every Alertmanager instance as a target, and the Alertmanager documentation advises against placing a load balancer in front of them. To run Alertmanager as a cluster for high availability, configure its cluster flags so instances share notification state. Confirm the flags and ports in the current Alertmanager documentation, then stop one instance in a test environment and verify that alerts still reach a receiver.
Configure the scrape, dashboards and alerts in sequence
This sequence moves Temporal metrics from each process into Prometheus, shows them in Grafana, and sends alerts before workflows stall. Each step closes with a check, so a fault is found before the next step depends on it.
Confirm metrics endpoints on every process
Before any scrape job is written, the operator confirms that each Temporal Service process, each worker and each client that should be observed exposes a metrics endpoint. The Temporal self-hosted deployment docs describe how to enable the endpoint for each service, and the team should record the address and port for every process in a shared inventory. The platform team usually does this with the Temporal owners, because application teams often deploy worker and client processes. This step is done when a direct request to each endpoint from the Prometheus host returns metric text, not a connection error or an authentication failure.
Add scrape jobs with discovery or static targets
Prometheus pulls metrics from the endpoints recorded in the previous step, using service discovery where the platform already publishes targets (for example, from Kubernetes) or static targets for fixed hosts. Give Temporal Service, worker and client targets separate job names so dashboards and alerts can filter by role. Keep scrape intervals and labels consistent across jobs, and store the configuration in version control. This step is done when the configuration validates and Prometheus reloads without errors.
Confirm targets are up and samples arrive
Open the Prometheus targets page and confirm that every expected endpoint shows as up. Then run a PromQL query on the up series grouped by job, and check that the count matches the inventory. Run a query on a Temporal metric for each role to confirm that recent samples are present. Prometheus stores samples in a local database with a default retention of 15 days, and local storage is not clustered or replicated, so confirm retention and disk sizing for the metrics you need before going further. This step is done when every expected target is up and each role returns recent samples.
Provision the Grafana data source and dashboards
Define the Prometheus data source and the Temporal dashboards as YAML or JSON provisioning files that Grafana loads at startup, so the setup can be reviewed and rebuilt from source control. Group dashboards by the job and role labels used in the scrape configuration, with panels for backlog, latency and failures across the Temporal Service, workers and clients. Grafana's provisioning docs also list other as-code options, including Terraform and Git Sync, for teams that prefer them. This step is done when a fresh Grafana instance started from the files shows a healthy data source and every panel renders data.
Write alert rules for backlog, latency and failures
Write Prometheus alert rules for three conditions: a growing task queue backlog, latency beyond an agreed threshold, and rising failure counts. Set thresholds from the baseline captured in the verification step and agree them with the workflow owners, because a value that suits one namespace may not suit another. Attach a severity label and a runbook reference to each rule so the on-call engineer knows the next action. This step is done when the rule files validate and each rule evaluates without errors on the Prometheus rules page.
Connect Prometheus to every Alertmanager instance
Configure Prometheus to send alerts to every Alertmanager instance in the cluster, listing each one directly. Prometheus should not send alerts through a load balancer. Alertmanager groups, inhibits and silences alerts, and its cluster flags let instances share state for high availability. Route alerts by severity to the receivers the on-call team uses, and keep the Alertmanager configuration in version control alongside the rules. This step is done when a test alert fires from a rule, reaches the receiver, and appears on every Alertmanager instance.
Wire and test the health check
Connect a health check to the Temporal Service endpoints and workers so that a failing process is detected even if the metrics pipeline is impaired. Confirm the health endpoints and their expected responses in the Temporal self-hosted deployment docs, then decide whether the check runs as Kubernetes probes, as a load balancer check, or inside the monitoring stack. Monitor the monitoring stack too, with an alert if Prometheus or Grafana stops responding. This step is done when stopping one test process triggers the health alert and restarting it clears the alert.
Which signals to collect and what each one tells operators
This table maps six signal categories to the process that emits them and the operator question each one answers. Use it as a checklist for what to collect before building dashboards, and treat backlog and latency as the first signals to alert on. Exact metric names and label sets vary by Temporal version, so confirm each one against the Temporal metrics reference for the server and SDK versions you deploy.
| Signal category | Source process | Question it answers |
|---|---|---|
| Temporal Service health | Frontend, history, matching and worker services of the self-hosted Temporal Server | Are the server services running, reachable and answering requests without a rise in errors? |
| Task queue backlog | Matching service, which holds tasks until workers poll for them | Are tasks waiting longer than workers can drain them, pointing to too few pollers or slow task handling? |
| Workflow and activity latency | History service for workflow progress, and worker processes for activity execution time | Where in the execution path is time accumulating, and are workflows finishing within the windows your team expects? |
| Worker poll and failure rates | Worker processes polling task queues through the Temporal SDK | Are workers polling successfully, and are workflow or activity tasks failing or retrying more often than usual? |
| Client errors | Application processes using Temporal SDK clients to start, signal or query workflows | Are callers getting failed starts, timeouts or rejected calls, and which namespaces or operations are affected? |
| Prometheus and Grafana self-metrics | Prometheus server, Alertmanager and the Grafana server | Are scrapes, rule evaluations, storage and alert delivery healthy enough to trust the other signals? |
Protecting the metrics path and the monitoring stack
Metrics endpoints and dashboards expose workflow backlog, service internals and sometimes version details that help an attacker plan. The cards below cover the network boundary around Temporal, the hardening settings for Grafana, and the authorization decisions that remain open in the Temporal server itself.
Restrict Temporal services to internal networks
The Temporal deployment docs say Temporal services should run on hosts that are not reachable from the public internet, with network access limited to trusted internal networks. For this monitoring setup, confirm that the frontend, internode and metrics ports are reachable only from the Prometheus servers, worker subnets and operator networks that need them. Verify the rules from outside the trusted network, not only from the firewall configuration.
Decide Temporal API authorization before go-live
If no Authorizer is configured, self-hosted Temporal uses the default noopAuthorizer, which allows every API request with no authentication or access control. Scraping metrics does not depend on this choice, but any client that can reach the frontend can act on namespaces. Confirm in the security docs which Authorizer, ClaimMapper and namespace role model your organization will use before the cluster is exposed to the monitoring network.
Separate Web UI sign-in and mTLS decisions
OIDC single sign-on for the Temporal Web UI and mTLS for internode and frontend traffic are separate choices, and each can be adopted without the other. Record which one protects which path in your design, and confirm the supported configuration for each in the Temporal self-hosted security documentation. Operators who scrape metrics or open dashboards need a documented access path that matches the chosen identity model.
Harden Grafana cookies and content policy
The Grafana security hardening guidance recommends secure and SameSite cookies and a Content Security Policy, and it also lists Trusted Types. Set these in the Grafana configuration, then test dashboards, annotations and plugin panels in a staging instance, because a strict policy can block panels that load external scripts. Record the chosen values so the same settings survive upgrades and redeployments.
Hide version and gate the metrics endpoint
The Grafana hardening guidance recommends hiding the version from unauthenticated users, and Prometheus scrape targets should require authentication before their metrics are readable from other hosts. Check what the Grafana login page and API reveal to anonymous visitors, and confirm which endpoints still answer without credentials after the change. Scrape credentials then need an owner, a rotation schedule and a place in your secrets management process.
Verify Grafana domain and DNS rebinding
The Grafana security hardening guidance recommends domain verification to protect against DNS rebinding, where a hostile site uses a name that resolves to an internal address to reach the dashboard. Set the root URL and domain settings to the exact hostname operators use, and test that requests with other host headers are rejected. Include this check in the acceptance tests for every Grafana instance that sits behind a load balancer.
Which Prometheus and Grafana release lines to pin
The first decision is whether to follow Prometheus's standard minor releases or its long-term support line. Prometheus begins a new minor release cycle every 6 weeks, and after those 6 weeks a minor release generally stops receiving bug fixes. A team on standard minors must therefore plan a move to a newer minor roughly every six weeks to stay patched. The current LTS line, 3.13, was released July 1, 2026 and receives fixes until July 31, 2027. For a monitoring stack that should change only on a planned schedule, that window is usually the more sustainable pin. Confirm the current patch cadence on the Prometheus release cycle page before you write it into an operating standard.
Grafana follows a different rhythm, and the difference matters when you plan Temporal dashboards that must stay stable for months. Grafana's upgrade guidance describes major releases once a year, usually in April or May, minor releases about every other month, and patch releases at least monthly. Each minor release is supported for 9 months, and the last minor release of a major version is supported for 15 months. Grafana 13.1.0 was released July 1, 2026, 13.2.0 on August 18, 2026, and patch releases 13.2.4, 13.1.8 and 13.0.11 on October 13, 2026. Check whether the minor you run is the last of its major version, because that changes how long it stays supported.
Pick the line your team can keep current without rushed changes. Ask who will test a new Prometheus minor against your scrape configuration, recording rules and alert rules, how long a staging run takes, who approves the change, and whether that person is also on call for Temporal. A team with limited upgrade capacity usually sustains an LTS Prometheus line and Grafana's monthly patches more reliably than a six-weekly minor track, but that is a judgment to test against your own staffing, not a rule. Record the exact Prometheus, Grafana and Alertmanager versions in your runbook so that an operator can see which lines are in use and when each one ends support.
Schedule monitoring stack upgrades separately from Temporal Server upgrades. Temporal Server should be upgraded one minor version at a time, moving first to the latest patch of the current minor, and schema upgrades must run before the server upgrade when the release notes call for them. Temporal Server v1.32.1 was published October 8, 2026, with patches v1.31.4 and v1.30.8 published October 12, 2026 for earlier lines. If a Prometheus or Grafana change lands in the same window, a missing panel or silent alert can be hard to trace to its cause. Keep a separate change calendar, and avoid starting a monitoring upgrade during a Temporal upgrade window.
Why dashboards go blank or alerts stay silent
This table lists the failures that most often leave Temporal dashboards empty or alerts quiet, with the likely cause and the check to run for each. Read each row from the symptom to the cause, then run the check before changing configuration. Most of these faults sit in scrape configuration, storage sizing, or how alerts reach Alertmanager and Grafana, so verify those first.
| Symptom | Typical cause | Fix and check to run |
|---|---|---|
| Targets stuck down after a Helm or server upgrade | Chart version no longer matches the server image, or service labels changed so scrape targets stop matching | Confirm the chart is 0.73.1 or later for server 1.30 and later, then check the Targets page for the last scrape error |
| Scrape jobs on the wrong port or path | Metrics port or path copied from an old example or not matched to each Temporal service | Compare each job's target and metrics path with your deployed services, then fetch the endpoint from the Prometheus host |
| Prometheus disk filling up | Retention never sized, so the default 15-day window applies regardless of series volume | Set retention by time and size, then alert on free disk space in the data directory |
| Single Prometheus losing history on restart | Local storage is not clustered or replicated, and no copy exists in long-term storage | Confirm remote write sends samples to external storage, then restart a test instance and look for gaps |
| Alertmanager duplicates or missing notifications | Prometheus sends alerts through a load balancer, which hides individual instances from Alertmanager clustering | Point Prometheus at every Alertmanager instance, then check cluster peers and send one test alert |
| Grafana alerts duplicated in an HA pair | Both active Grafana servers evaluate and send alerts unless HA alerting is configured | Apply the HA alerting settings for your Grafana version, then fire a test alert and count receiver notifications |
| Grafana Live panels stale in HA | Grafana Live has documented limitations across HA nodes behind a load balancer | List the live features you use, then test panel updates with users landing on different nodes |
Alert on backlog and latency before workflows stall
Set alert thresholds from your own baseline before any alert is allowed to page someone. Run the Temporal cluster under representative load long enough to see daily and weekly peaks, then record task queue backlog and workflow and activity latency for each namespace and task queue. Set thresholds above what your normal peaks produce. Example values from documentation or community dashboards are starting points for discussion only, because your workflow mix, worker counts and downstream dependencies determine what slow means. Record who owns each threshold and when it is reviewed. Because Prometheus local retention defaults to 15 days, extend retention or send samples to long-term storage through remote write so the baseline covers a full business cycle.
Keep deployments from flooding the on-call channel. Alertmanager groups related alerts into one notification, so a rollout that restarts many workers produces one message per affected task queue. Inhibition suppresses dependent alerts while a root alert is firing, for example a worker-down alert can suppress latency alerts for the same task queue. Silences mute known alerts for a fixed window during a planned change. Tie each silence to a change ticket, scope it to the affected namespace or task queue, and set an expiry so it cannot outlive the change. Confirm that the label names in your rules match the matchers in your routes. If notifications must survive one Alertmanager instance failing, run Alertmanager as a cluster using its cluster flags and point Prometheus at each instance directly, as the Alertmanager documentation advises against placing a load balancer in front of them.
Worker failures and capacity warnings need different routes. A task queue with no active pollers, crashing workers or sustained activity failures means work is stalling now, so it should page the on-call engineer with a defined response expectation agreed with the owning team. A backlog that is growing slowly or latency drifting above baseline is a capacity warning. It usually calls for scaling or investigation during working hours, so it belongs in a ticket queue or a team channel. Route on a severity label set in each rule, keep the paging route narrow, and let the worker-down alert inhibit capacity alerts for the same task queue. Review the routes after each incident to confirm that pages led to action and warnings did not wake anyone.
Prometheus values reliability over precision, and its documentation says it is not a good choice where 100% accuracy is required, such as per-request billing. Scrape intervals, missed scrapes and local storage that is not clustered or replicated mean a metric can miss events. Treat alerts as operational signals, not as proof that every workflow was processed. If a business process requires that every workflow started is accounted for, design a separate completeness check. Reconcile workflow execution counts against a system of record on a schedule, using queries your visibility store supports reliably, and give that check its own alerting and a named owner. Confirm with your Temporal version and visibility store which queries are dependable before you build the check on them.
Questions teams ask before scoping this monitoring work
How much does it cost to run Prometheus and Grafana for Temporal?
Prometheus has no license fee and no paid enterprise edition, so its cost comes from four places: infrastructure to run the Prometheus servers, storage for metrics, implementation work, and the staff who operate the stack. Infrastructure and storage recur every month and grow with the number of series you collect and how long you keep them. Implementation is mostly one-time work covering exporters, scrape configuration, dashboards, alert rules and routing. Operating time recurs for upgrades, alert tuning and on-call response. Grafana is a separate choice. It is licensed under AGPLv3, and Grafana Enterprise and Grafana Cloud carry their own pricing. The Grafana pricing page lists current figures, including a 19 US dollar monthly platform fee for the Cloud Pro tier plus usage. Ask any provider for a quote that separates one-time work from recurring infrastructure and support.
Do we need Grafana Enterprise or Grafana Cloud to monitor Temporal?
No single Grafana edition is required to build dashboards and alerts for Temporal metrics, so the choice depends on identity, support and hosting needs. Grafana authentication supports LDAP, generic OAuth, Entra ID, Okta, GitHub, GitLab and Google OAuth in all editions. SAML, team sync, active sync and SCIM provisioning are available only in Grafana Enterprise and Grafana Cloud, so check those requirements first. Self-hosted Grafana needs MySQL or PostgreSQL for production and high availability, because SQLite does not scale for production. Grafana Enterprise is a commercial option, and Grafana Cloud is priced by tier. The Grafana pricing page lists the Enterprise minimum commitment and the Cloud tier structure. Confirm your identity and hosting requirements before choosing an edition.
How long does a Prometheus and Grafana monitoring project take?
Duration depends mainly on three things: the number of Temporal services and worker deployments to monitor, the number of environments that need coverage, and how alert routing is agreed. A single environment with a small number of services and one agreed set of receivers is much shorter to build than several environments with separate escalation paths for each team. Dashboards and alert rules take less time once metric names and labels are settled, so decisions about naming and ownership early in scoping shorten the build. Most DeployOpen engagements are fixed-scope, so the timeline is written into the agreed scope before work starts. Ask for the timeline to be tied to named environments, named services and a named alert routing model.
What do we need to provide before a monitoring scope is written?
Prepare the facts that determine how Temporal is deployed and how it is reached. List the Temporal Server version and how it is deployed, whether by Docker Compose, Go binaries, Helm charts on Kubernetes or a custom Go build. Name the persistence store and the visibility store. Confirm which networks Prometheus can reach to scrape Temporal services and workers, given that Temporal services should not be reachable from the public internet. Identify the environments in scope, the teams that will receive alerts, their escalation paths and any on-call rota. State your retention requirements for metrics and who needs dashboard access, including whether SSO is required. Share any existing observability tooling so the design can reuse it rather than duplicate it.
Can our internal platform team set up Temporal monitoring without a partner?
Yes, an internal team can do this if it already operates Prometheus, Grafana and the hosts or Kubernetes clusters that run Temporal, and if it has the time to own the work after handover. The Prometheus and Grafana documentation covers installation, scrape configuration, provisioning and high availability in detail. Teams without that operating experience often find the hard parts are alert design, routing and tuning, not installation. An external partner can help when scope is wide, timelines are tight, or an independent review of alert design is needed. A reasonable first step is a single-environment pilot run by your own team, with the results used to decide whether to extend it. Agree who owns each dashboard and alert rule before handover.
How long does Prometheus keep Temporal metrics by default?
Prometheus keeps data for 15 days by default, and you can change retention by time or by size. Its local time series database stores samples in two-hour blocks with a write-ahead log. Local storage is not clustered or replicated, so the Prometheus server should be managed like any other single-node database, with capacity planning, disk monitoring and a tested recovery procedure. For longer retention, Prometheus can send samples to external long-term storage through its remote write protocol and read them back through remote read. Decide retention early because it drives disk size and storage cost. Confirm with your team which retention periods are needed for incident review, capacity planning and any internal records policy.
Should we run Prometheus LTS or the latest minor release?
Run the long-term support line if you want bug fixes for a fixed period, and plan upgrades around that window. A new Prometheus minor release starts every six weeks, and a minor release generally stops receiving bug fixes after those six weeks. Long-term support releases receive bug fixes for one year. The current LTS line is 3.13, which is supported until July 31, 2027. The latest minor release at the time of writing is v3.15.0, so check the release cycle page before choosing. Alertmanager should be run as a cluster when high availability matters, and Prometheus should be configured to send alerts to every Alertmanager instance rather than to a load balancer. Confirm which line fits your upgrade cadence before the build starts.
How DeployOpen scopes and delivers Temporal monitoring
DeployOpen scopes Temporal monitoring as a written, fixed-scope engagement covering Prometheus collection, Grafana dashboards, alert rules and health checks in infrastructure you control. The work runs in your environment, from Temporal Service and worker metrics through to handover, with the monitoring stack documented so your operators can run it. Ongoing support, tuning and upgrades can follow as a retainer.
How we scope
- The written scope lists the Temporal Service, client and worker metrics to collect.
- It also defines the dashboards, alert rules and health checks to build, and who receives alerts.
- Scope confirms the Prometheus, Grafana and Alertmanager components and where each one runs.
How we build
- Prometheus is configured to scrape Temporal targets found through service discovery or static configuration.
- Grafana data sources, dashboards and alert rules are defined as provisioned files that can be version-controlled.
- Alertmanager is set up for grouping, silences and, where required, a clustered high availability design.
How we hand over
- Handover includes configuration files, provisioning definitions, dashboard exports and alert runbooks.
- Operators receive a walkthrough of backlog, latency and failure panels and what each alert means.
- Prometheus local storage is single-node, so retention and any remote write target are documented for your team.
How we support
- Ongoing support, tuning and upgrades for Prometheus, Grafana and Alertmanager can run as a retainer.
- Upgrade planning follows each component's release cycle, including Prometheus long-term support lines.
- Confirm with your team who owns alert response and how monitoring findings reach Temporal operators.
