Monitoring Apache Kafka with Prometheus and Grafana

How to monitor Apache Kafka with Prometheus and Grafana

If you run a self-hosted KRaft cluster, you need alerts that fire before application teams notice a problem. Kafka exposes its internal state as JMX MBeans, which are not readable by Prometheus directly. The JMX exporter solves this: it is an Apache 2.0 collector from the prometheus/jmx_exporter project that reads MBean values and presents them in Prometheus format. It ships in two forms, as a Java agent attached to each Kafka JVM and as a standalone process that queries JMX remotely. This page covers those paths, plus two Kubernetes-oriented options: the metrics built into Strimzi, and Kafka Exporter for consumer group lag, which JMX does not expose per group in the form most teams need.

The scope is deliberately narrow. This page covers how metrics reach Prometheus from KRaft controllers and brokers, how Prometheus scrapes them, and the structure of Grafana dashboards for brokers, topics and consumers. It does not cover choosing which alerts to set or their thresholds, which belong to the sibling page on key Kafka metrics, and it does not cover consumer lag analysis or troubleshooting. Before you start, confirm the Kafka version you run and the exporter release that supports it, since the exporter's MBean mappings change with Kafka releases. Also confirm whether your Kafka JVMs allow a Java agent or a remote JMX port, because your security team may restrict the second. Prometheus local storage is single-node and not replicated, so plan retention and any long-term storage before the dashboards depend on them.

Grafana sits on top of Prometheus as the query and visualization layer. Its own production setup needs a MySQL or PostgreSQL database rather than the default SQLite, and high availability requires two or more active-active servers behind a load balancer. Confirm which Grafana release line your organization will standardize on and how its upgrade cadence fits your change process. Ask your DeployOpen contact, or confirm with the project documentation, which exporter configuration rules fit your Kafka version before you copy any example into production.

What you need before scraping Kafka metrics

Most metric gaps come from decisions made before the first scrape: which Kafka line you run, which Grafana backend holds its state, and whether Prometheus can reach every controller and broker. The cards below cover those prerequisites and the checks to make before you write any scrape configuration.

Target a supported Kafka line

Confirm whether your cluster runs 4.1.x, 4.2.x or 4.3.x, the lines the downloads page lists as supported. Brokers need Java 17 from Kafka 4.0 onward, and the JVM version determines which JMX exporter build you can load as a Java agent. Check the running version and JVM on every controller and broker, because a mixed upgrade in progress can leave you with two sets of metric names to handle.

Match the JMX exporter build

Pick the JMX exporter release that supports your Kafka and Java versions, then decide between the Java agent and the standalone mode. The agent runs inside each broker and controller process, so every node needs the jar and a rules file. Record the exporter version in your change log, since rules written for one Kafka release may need edits after an upgrade.

Confirm Prometheus release line

Check the current Prometheus release line before you pin a version. Minor releases stop receiving bug fixes after six weeks, so an unpinned minor version can fall out of support quickly. If you need a longer patch window, choose the long-term support line and confirm its end-of-support date on the release cycle page before you build around it.

Plan Prometheus local storage

Local Prometheus storage is a single-node database, so it is not clustered or replicated. The default retention is 15 days, which you should compare with the window your capacity and incident reviews need. Size disk for the retention you choose, and decide early whether long-term data goes to remote write storage.

Choose a production Grafana database

Grafana stores configuration in SQLite by default, but the installation docs say SQLite does not scale for production. Use PostgreSQL 12 or later or MySQL 8.0 or later for any shared or highly available Grafana. Confirm the Grafana release line you plan to run, since minor releases are supported for a limited period and upgrades should follow the release guidance.

Open paths to metrics ports

Prometheus must reach the JMX exporter port on every controller and broker, and the Kafka Exporter port if you use one. Check firewall rules, security groups and any network policies between the monitoring network and the Kafka nodes. Decide whether metrics endpoints use TLS or authentication, because the security hardening guidance recommends requiring authentication for the metrics endpoint.

Which metrics path fits your deployment

On virtual machines and bare metal, the usual path is the Prometheus JMX exporter running as a Java agent inside each broker and controller JVM. The agent reads MBeans from within the process and serves them over HTTP for Prometheus to scrape. The project also ships a standalone mode that connects to JMX remotely, which moves the trust boundary to the JMX port, so the choice belongs in your security review.

What it exposes: broker and controller MBeans such as partition state, replication, request handling and JVM figures, selected and renamed by rules in a YAML configuration file.
What it does not expose: consumer group lag. Broker JMX holds no per-group offset view, so lag must come from Kafka Exporter, client-side metrics or a dedicated lag collector.
Who maintains it: the platform team owns the agent jar version, the rules file and the service unit that loads them. Each Kafka upgrade should include a check that the rules still match the MBean names in that release.
Access control: the metrics endpoint should be reachable only from Prometheus and authenticated where your setup allows. Confirm the exporter's options for your version before opening the port.

Before relying on the setup, confirm that every broker and controller target is up in Prometheus and that the rules file matches the Kafka version you run.

Configuring the JMX exporter, scrape targets and dashboards

This sequence moves each Kafka controller and broker from unmonitored to visible in Grafana. Each step ends with a check, so the agent, scrape jobs and dashboards are verified before anyone relies on them. The Kafka Exporter adds the consumer group lag view that broker-side metrics do not provide.

Decide JMX access and enable it on each node
On every controller and broker, decide whether the exporter runs as a Java agent inside the Kafka process or reads a remote JMX port, and record the choice per node. Running in-process keeps remote JMX off, which reduces exposure. If you use a remote port, enable it in the start configuration with authentication and TLS, and treat it as an administrative interface because it can expose management operations as well as metrics. Restart one node and confirm the JVM starts cleanly with the new settings before rolling the change to the rest of the cluster.
Attach the JMX exporter agent with a rules file
Obtain the JMX exporter jar from the project's official repository, verify it against the release you pin, and add it to the Kafka JVM options as a Java agent with a port and a path to a rules file such as config.yaml. Write rules that keep broker, controller, request, network, log and KRaft metadata metrics, and drop per-partition or per-client series you do not need, because cardinality drives Prometheus storage and query cost. Check the result by restarting the node and requesting the local metrics endpoint, which should return metric names with the kafka_ prefix.
Expose the metrics port to Prometheus only
Open the metrics port on each node's host firewall or security group for the Prometheus server address only, and keep it closed to other networks. Prometheus pulls metrics over HTTP, so the port must be reachable from that server but not from application subnets or the internet. Decide whether the endpoint needs authentication, consistent with your Prometheus security model, and document the choice. Check the result from the Prometheus host, where the request should succeed, and from an unapproved host, where it should fail.
Define separate scrape jobs for controllers and brokers
In the Prometheus configuration, create one scrape job for controllers and one for brokers, using static configuration or service discovery that matches your deployment. Keeping them apart lets you query controller-only signals, such as active controller count and KRaft metadata metrics, without filtering out broker series. Set labels that identify the cluster and role, and choose a scrape interval that matches your alerting needs. Check the result on the Prometheus targets page, where every controller and broker should show as UP, and run a query on up filtered by each job to confirm one series per node.
Add Kafka Exporter for consumer group lag
Run Kafka Exporter as its own process, point it at the cluster's bootstrap servers, and give it client credentials with read access to consumer groups and topics. Those permissions depend on the authorization model you configured, so confirm them in your ACLs before deployment. Add a separate Prometheus scrape job for the exporter. Confirm the metric names and labels against the exporter's own documentation for the version you deploy. Check the result by querying consumer lag per group and topic, then pause a test consumer and confirm the lag value climbs.
Provision the Grafana data source and dashboards
Define the Prometheus data source and the broker, topic and consumer dashboards as provisioning files that Grafana loads at startup, following the Grafana provisioning documentation. Store the dashboard JSON in version control so changes are reviewed and reproducible across environments. Import any community dashboards only after you have checked their queries against your metric names and labels. Check the result by restarting Grafana, confirming the dashboards appear without manual edits, and verifying that each panel returns data.

Which Kafka metrics to scrape and why cardinality matters

Start from a deliberate allowlist of metrics, not every MBean the JMX exporter can read. The JMX exporter, which runs as a Java agent alongside each broker and KRaft controller, can expose a very large number of MBeans. Each unique combination of metric name and label values becomes a separate time series in Prometheus, so exporting everything multiplies storage, query load and scrape time before anyone has looked at a graph. A first rules file should cover broker health (online state and active controller count), partition state (under-replicated, offline and at-minimum-ISR partitions), KRaft quorum signals on controllers, request latency and error rates for produce and fetch, and per-topic byte and message throughput. Confirm the exact MBean names against the version of Kafka you run, since they are defined by the broker and exporter configuration rather than by this page.

Treat per-partition and per-client metrics as opt-in, because they grow with your topology. Series counts scale with the number of partitions, topics, client IDs, consumer groups and their members, so a cluster that adds a few hundred partitions or a new application with many short-lived clients can change the cost of your Prometheus server without any visible change in workload. Consumer lag is usually better measured by a dedicated exporter that reports per-group figures than by scraping per-client MBeans, and that choice belongs in the consumer lag page. Prometheus favors reliability over precision, so the Prometheus overview is explicit that it is not the right tool where every request must be accounted for exactly. Build dashboards and alerts around trends, rates and sustained conditions, and keep exact accounting in Kafka's own tooling or your billing and audit systems.

Mapping Kafka components to Prometheus jobs and dashboards

This table maps each part of a Kafka deployment to its metric source, scrape job, dashboard group and alert owner. Read it as a checklist when you decide which targets Prometheus scrapes and which team answers each alert. The main takeaway is that controllers, brokers, topic-level views and consumer groups come from different sources, so each needs its own job and its own owner.

Component	Metric source and scrape job	Question it answers and dashboard	Alert owner
KRaft controllers	JMX exporter agent on each controller, scraped as a dedicated controller job	Is there one active controller and is metadata replication healthy? Cluster health dashboard	Platform team running the Kafka cluster
Brokers	JMX exporter agent or Strimzi metrics config on each broker, scraped as a broker job	Are partitions online, replicated and handling requests within normal latency? Broker health dashboard	Platform team running the Kafka cluster
Partition and replica state	Broker-side JMX metrics for partition counts and replica state, read from the broker job	Are any partitions under-replicated or offline? Replication dashboard	Platform team, with on-call escalation to application owners
Topics	Broker-side per-topic JMX metrics, read from the broker job; confirm the exact label set in your exporter config	Which topics carry the most traffic and where are errors arising? Topic throughput dashboard	Topic owners, through a routing rule per team
Consumer groups	Kafka Exporter (or equivalent) scraped as a separate consumer job, since group offsets are not exposed by brokers over JMX alone	Is each group keeping up or falling further behind? Consumer lag dashboard	Application team that owns the consumer group
Client-side consumer metrics	Client JMX or application metrics, scraped from application jobs where the team exposes them	Are individual consumers stalled or rebalancing? Consumer application dashboard	Application team
Kafka Exporter	Separate exporter process with its own scrape job; confirm which group and topic metrics your version exposes	Lag and offset values per group and partition for alerting and dashboards	Platform team, with the Prometheus instance it reports to
JVM and host runtime	JVM and node exporter metrics on each controller and broker, in the same jobs as Kafka	Is the JVM under memory or garbage collection pressure, or is the host short on disk? Host and JVM dashboard	Platform team running the infrastructure

Securing the metrics path

Metrics endpoints expose broker internals and, when JMX is left open, management interfaces. The controls below cover the three places the metrics path can leak or be tampered with: the JMX and exporter endpoints on Kafka nodes, the network path Prometheus uses to reach them, and the Grafana server that displays the results.

Require authentication on JMX

Remote JMX is a management interface, not just a read path. Disable unauthenticated remote JMX and, if it is enabled, require credentials and TLS for it. Keep the Prometheus JMX exporter on its own HTTP port so the exporter, not raw JMX, is what Prometheus scrapes. Check the JVM flags on every controller and broker, since a remote JMX port left open by a copied startup script is a common gap. Confirm the exact flags against your Kafka and Java versions before rollout.

Restrict the endpoint to Prometheus

The exporter port should accept connections only from the Prometheus servers or scrape proxies that need it. Enforce this with host firewall rules, cloud security groups or Kubernetes network policy, and deny it to application subnets and general user networks. Verify the rule from a host that should be blocked, not only from the Prometheus host. Record the allowed source addresses, because Prometheus server moves are a frequent cause of silent scrape failures after a rule is tightened.

TLS between scrapers and targets

Prometheus can be configured to scrape over HTTPS with TLS settings per scrape job, and the JMX exporter itself does not provide the same transport guarantees as a TLS-terminating proxy. Where the metrics cross a network you do not fully control, plan a TLS termination point and certificate rotation for the scrape targets. Confirm which scrape TLS options your Prometheus version and exporter setup support before you write the design, and keep the certificate lifecycle in the same process as broker certificates.

Authenticate the Grafana metrics endpoint

Grafana exposes its own metrics endpoint, which reveals operational detail about the Grafana server. The security hardening guidance recommends requiring authentication for it and hiding the Grafana version from unauthenticated users. Add these settings to the Grafana configuration, then confirm from an unauthenticated client that neither the metrics nor the version string is returned. Record the settings in version control so upgrades do not silently reset them.

Cookies, CSP and identity choice

Enable secure and SameSite cookie settings, define a Content Security Policy and review Trusted Types support for the Grafana version you run. Then choose the sign-in method before designing access. LDAP, generic OAuth, Entra ID, Okta, GitHub, GitLab, Google OAuth, auth proxy and JWT are available across editions, but SAML, team sync, active sync and SCIM provisioning are Grafana Enterprise or Grafana Cloud features. Confirm which identity option your organization needs before you commit to a design.

Running Prometheus, Alertmanager and Grafana over time

Plan for the monitoring stack to be a stateful service in its own right, because the Kafka dashboards are only as useful as the history behind them. Prometheus stores samples in a local time series database, and its storage documentation states that local storage is not clustered or replicated. A single Prometheus server is therefore a single point of failure for metrics, and its disk should be managed like any other single-node database, with volume sizing, snapshots and a restore test. The default retention is 15 days, configurable by time or size through the retention flags. If you need Kafka capacity trends across quarters, decide early whether to send samples to long-term storage through remote write, which the storage documentation describes as the protocol for sending samples to external systems. Confirm the retention and storage backend you will use with the vendor documentation before you size disks, because the choice changes what the Kafka dashboards can show.

Alertmanager needs the same care. It supports clustering through its --cluster flags for high availability, and Prometheus should be configured with every Alertmanager instance listed in its alerting configuration rather than pointing at a load balancer. Test that a Kafka alert reaches the receiver when one Alertmanager node is stopped. For Grafana, high availability means two or more active-active servers behind a load balancer, sharing a PostgreSQL or MySQL database. SQLite is not suitable for production or high availability, so the database choice is a day-one decision. Be aware of the duplicate alert caveat: the high availability documentation says alerting needs additional configuration to avoid duplicate notifications, and Grafana Live has limitations in that mode. Decide which alerting engine owns Kafka paging rules before you enable a second node.

Version currency is the last operational risk. Prometheus minor releases receive bug fixes for about six weeks, so run a long-term support line if you want fixes for a full year. The current LTS line is 3.13, supported until July 31, 2027, according to the Prometheus release cycle page. Grafana publishes major releases once a year, minor releases every other month and patches at least monthly, with each minor release supported for 9 months. Put Prometheus, Alertmanager, Grafana and the JMX exporter on a written upgrade calendar, test dashboards and alert rules against each new release in a non-production stack, and confirm the support window for each component in its own release documentation before you commit to a cadence.

Common failures when Kafka metrics stop reaching Grafana

This table lists the failures that most often stop Kafka metrics from reaching Grafana, with the symptom you see, the likely cause and the check that confirms the fix. Read it from the top when a dashboard goes blank or an alert stops firing, and use the verification step to confirm the repair before closing the incident.

Failure	Symptom	Likely cause	Fix and how to verify
Agent not attached after an upgrade	Broker metrics disappear after a Kafka or Java upgrade, while the broker itself runs normally	The JMX exporter Java agent is referenced in the startup options, but the path or version no longer matches the new Kafka or Java install	Update the agent path and version in the startup configuration, restart a single broker, then confirm its metrics endpoint returns kafka_ series again before rolling the rest
Rules file drops needed metrics	Some dashboard panels show no data while others work; the metrics endpoint responds but returns fewer series	The exporter rules file excludes or renames MBeans that a dashboard or alert depends on	Compare the rules file with the metric names each panel queries, add the missing rules, then check the target in Prometheus for the expected series count
JMX port conflict	The exporter fails at startup or the target shows down; broker logs show a bind error on the monitoring port	Another process, or a second broker on the same host, uses the port set for JMX or the exporter	Assign a unique port per process, confirm with a listening-socket check on each host, then verify the target reports up in the Prometheus targets view
Scrape timeouts on large clusters	Targets flap between up and down, with scrape duration close to or above the configured timeout	Many MBeans, high partition counts or a slow exporter response exceed the scrape timeout	Raise the scrape timeout within the scrape interval, trim unneeded MBeans in the rules file, and check the scrape duration series after the change
Consumer lag missing	Lag panels are empty while broker metrics still arrive; the Kafka Exporter target reports errors	Kafka Exporter cannot reach the bootstrap brokers because of network policy, TLS or SASL settings that do not match the listener	Test connectivity from the exporter host to the bootstrap listener, align its security settings with the broker listener, then confirm a lag series returns for a known consumer group
Dashboards broken by renamed metrics	Panels show no data or errors after a version change, though the same data is still exposed under a different name	A Kafka, exporter or Strimzi release renamed or relabeled metrics, so queries no longer match	Compare the metric names on the endpoint with the queries in each panel, update the queries or recording rules, and version-control the dashboard JSON so the change is reviewed
Duplicate Grafana alerts in HA	Two notifications arrive for each alert after moving Grafana to two or more active servers	Each Grafana instance evaluates alert rules and sends notifications because alerting was not configured for HA	Apply the alerting HA settings described in the Grafana high availability docs, then trigger a test alert and confirm exactly one notification arrives per event

Questions buyers ask about Kafka monitoring

How much does it cost to monitor Kafka with Prometheus and Grafana?

The software is free to license, so the cost comes from the people, infrastructure and storage around it. Prometheus is licensed under Apache-2.0 and has no paid enterprise edition, and Grafana offers an open-source edition alongside Grafana Enterprise and Grafana Cloud, which are separate commercial options. The main recurring costs are the servers that run Prometheus, Grafana and Alertmanager, the storage for metric history, and the engineering time to keep exporters, dashboards and alert rules current across Kafka upgrades. Ask any quote to separate one-time work (exporter configuration, dashboards, alert rules) from recurring work (upgrades, retention changes, on-call tuning) and to name every component it covers.

How long does a Kafka monitoring setup take?

Duration depends on how many clusters, brokers and controllers need scraping, whether the JMX exporter agent must be added to running brokers, how many dashboards and alert rules the team wants, and whether Prometheus and Grafana already exist in your environment. A single cluster with an existing Prometheus stack is a much smaller job than a multi-site estate with new monitoring infrastructure. Ask the scope to list the number of clusters, the dashboards by audience (brokers, topics, consumers), the alert routes and the environments to be covered, then agree the timeline in writing before work starts. DeployOpen plans each engagement from a written scope, so the timeline follows from that scope.

What does our team need to provide for the work?

The work needs access to the Kafka brokers and controllers, a place to run Prometheus and Alertmanager, and a Grafana instance or the approval to deploy one. It also needs a rolling restart window, because the JMX exporter runs as a Java agent that is attached when the broker JVM starts. On the Grafana side, plan for a production database: Grafana stores configuration in SQLite by default, but its installation docs say SQLite does not scale for production, so MySQL or PostgreSQL is required for production and high availability. Your team should also name who receives alerts, who owns the thresholds and who approves changes to shared dashboards.

Can our own team monitor Kafka without a partner?

Yes, a team that already runs Prometheus and Grafana and has Kafka operators can build this internally, because both tools are open source and the metric names are documented by the Kafka and exporter projects. The work becomes harder when the team is new to JVM metrics, when Kafka runs on Kubernetes with Strimzi, or when alert thresholds must be tuned against real traffic. Ask yourself who will update the exporter rules after a Kafka upgrade and who will answer the page at night. A partner can take on the build and hand over runbooks, and the handover should cover what your staff must do after go-live.

Should we use Grafana Enterprise or Grafana Cloud for dashboards?

Open-source Grafana covers dashboards, alerting and the data sources this setup needs, so the choice is about operating model and features, not about whether monitoring works. Grafana Cloud has a free tier, a Pro tier that starts with a 19 US dollar monthly platform fee plus usage, and an Enterprise tier with a minimum commitment of 25,000 US dollars per year, according to the Grafana pricing page. Grafana Enterprise adds SAML, team sync and SCIM provisioning, which the open-source edition does not include. Confirm current pricing and feature lists directly with Grafana before you decide, because the figures above are the ones supplied at research time.

What should a written scope for Kafka monitoring include?

A useful scope lists the clusters, the broker and controller hosts, the JMX exporter method, the Strimzi or Kafka Exporter components where used, and the Prometheus and Alertmanager topology. It also names the dashboards by audience, the alert rules with owners, the retention period and storage size for metrics, the Grafana database and authentication method, and the provisioning approach for dashboards and data sources. Include the test steps, such as confirming every target is scraped and every alert fires in a controlled test, and the handover items, such as runbooks and upgrade steps. Finally, list what is excluded, for example consumer lag exporters or log monitoring.

Is Prometheus reliable enough for production Kafka alerts?

Prometheus is designed for reliability over precision, and its documentation says it is not the right choice where 100% accuracy is required, such as per-request billing. For Kafka alerting, that is usually acceptable, but the design must account for it. Local Prometheus storage is not clustered or replicated and should be managed like any single-node database, so plan backups or a remote write target for long-term data. Alertmanager can run as a cluster for high availability, and Prometheus should point at every Alertmanager instance rather than a load balancer. Confirm these points against your alert paging requirements before go-live.

How do we keep the monitoring stack current after Kafka upgrades?

Treat the monitoring stack as part of each Kafka upgrade. Kafka's time-based release plan supports rolling upgrades from each release in the past year to the latest version, and new Kafka versions can change metric names or add metrics that dashboards should use. Prometheus publishes a new minor release every six weeks, and a minor release generally stops receiving bug fixes after those six weeks, while long-term support releases get fixes for one year. Grafana releases minor versions every other month and patches at least monthly. Plan a recurring review that covers Kafka, the JMX exporter, Prometheus, Grafana and Alertmanager together.

License terms that affect your monitoring stack

The license terms of the three core components differ, so check them before you build. The Prometheus JMX exporter and Prometheus itself are both licensed under the Apache License 2.0, and Prometheus has no paid enterprise edition, so the project's own license does not add a fee. Your costs come from the infrastructure, the storage, the implementation work and the people who run the stack. The JMX exporter ships as a Java agent that attaches to each Kafka broker and controller, which means its license sits inside your Kafka runtime, and it should be recorded in the same software inventory as Kafka itself.

Grafana is different. On April 20, 2021, Grafana Labs relicensed Grafana, Loki and Tempo from Apache License 2.0 to *AGPLv3*. Plugins, SDKs and agent software kept other licenses, and Grafana Enterprise is offered as a non-AGPL commercial option. The AGPL carries source-availability obligations for modified versions that users interact with over a network, so a team that patches Grafana, embeds its dashboards in another product or offers Grafana-based views to outside parties should not assume the terms are the same as the Apache-licensed components. The license page on Grafana Labs licensing lists the current terms for each product.

Before you embed, redistribute or host this stack for anyone outside your organization, ask your legal or open-source compliance team to confirm the license fit for each component, including any plugins you install. Record the version and license of every artifact in your deployment, and confirm whether the Enterprise edition is needed for features such as SAML, which the Grafana authentication documentation lists as Enterprise-only. This review is a legal question, not an engineering one, so put it on the plan before dashboards are shared beyond the platform team.

How DeployOpen works on this

DeployOpen plans, builds, documents and supports Kafka monitoring inside your own infrastructure, so the metrics pipeline, dashboards and alert rules stay under your control. Each engagement starts from a written scope that names the brokers, controllers, exporters and dashboards covered.

How we scope

Inventory every broker, KRaft controller and client group that needs metrics before any exporter is configured.
Agree in writing which dashboards for brokers, topics and consumers are in scope, and which alerts they feed.
Confirm the Prometheus, Alertmanager and Grafana hosting model, retention targets and access rules for your environment.

How we build

Attach the JMX exporter as a Java agent to each broker and controller, with a rules file reviewed against your Kafka version.
Configure Prometheus scrape jobs for controllers and brokers, and add Kafka Exporter for consumer group lag where needed.
Provision Grafana data sources and dashboards as code, and test that each alert rule fires against a controlled fault.

How we hand over

Deliver a runbook that explains each dashboard panel, alert rule, threshold and the first response step.
Document every exporter version, configuration file and provisioning repository so your team can reproduce the stack.
Walk your operators through a live alert and a dashboard review before the handover is closed.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades of the exporter, Prometheus and Grafana, and continuous testing are available as a retainer.
Request a quote from the written scope, which sets the cost of build work and any retainer for later changes.