APISIX Prometheus monitoring: setup and alerts

How Apache APISIX monitoring with Prometheus works

A team running APISIX as its API gateway needs to know whether the gateway is healthy and how traffic is behaving before users notice a problem. APISIX exposes its metrics on an HTTP endpoint that Prometheus pulls on a schedule, so the integration is configuration on both sides rather than a separate plugin you have to build. On the APISIX side, you enable the Prometheus plugin and expose its metrics endpoint. On the Prometheus side, you add a scrape job that points at that endpoint from each gateway instance, either through static configuration or service discovery if your gateways are created and removed automatically.

Confirm the default metrics endpoint address and port against the APISIX monitoring documentation for the exact version you deploy, and record them in your runbook. Do not assume the gateway's client port or Admin API port carries metrics. Also confirm how the metrics listener is bound and whether it is reachable only from your monitoring network, because the metrics output reveals route and service names. Each gateway instance is a separate scrape target, so plan for one job entry per instance or a discovery rule that finds every instance in your traditional, decoupled or standalone deployment.

This page covers metrics only. It does not cover distributed tracing, access log shipping or dashboard design, which have their own pages in this group. Keep in mind that Prometheus stores data on a single node by default and values reliability over precision, so the scrape interval, retention and any long-term storage choice should be decided before you rely on the data for alerts.

What you need before scraping APISIX metrics

Scraping APISIX metrics depends on four things lining up: the gateway version you pin, the deployment mode and the ports it exposes, a Prometheus release that still receives fixes, and a network path from Prometheus to the metrics port. Alerting needs a plan too, because Prometheus only raises alerts that an Alertmanager instance delivers.

Pin the APISIX version

Start from the version you will run in production, not the newest download. The downloads page lists APISIX 3.19.0 as the latest release, released September 28, 2026, and does not mark any release as long-term support. Record the exact version in your configuration management, because metric names and labels can change between releases. Confirm with your change board which upgrade path applies if you are on an older line, and read the release notes for the version you choose before you write alert rules against its metrics.

Confirm the deployment mode

APISIX runs in traditional, decoupled or standalone mode, and the mode decides where the Admin API lives and which ports you open. In traditional mode, client traffic arrives on port 9080 and the Admin API listens on port 9180. Write down which mode each environment uses, since a scrape target list built for one mode will miss gateways running in another. Ask your platform team whether the metrics endpoint is reachable on each data plane node you intend to scrape.

Choose a supported Prometheus line

Pick a Prometheus release that still receives bug fixes. The current long-term support line is 3.13, released July 1, 2026 and supported until July 31, 2027, which suits a stable monitoring stack. Minor releases only receive fixes for about six weeks, so a non-LTS server will fall behind quickly. Confirm the version you deploy in the release cycle page and plan the next upgrade before the support window ends.

Open the path to the metrics port

Prometheus pulls metrics over HTTP, so every gateway node needs a route from the Prometheus server to the metrics endpoint. Check security groups, host firewalls, network policies and any load balancer between them. Keep the Admin API port closed to the scraper, because metrics and Admin API access are separate concerns. Ask the security team to document which source addresses may reach the endpoint, and review whether that endpoint should be restricted to the monitoring network.

Plan the Alertmanager setup

Prometheus evaluates alert rules, but Alertmanager groups, silences and routes the notifications. Decide before the first scrape whether you will run one Alertmanager or a clustered set for high availability. Prometheus should list every Alertmanager instance directly rather than pointing at a load balancer. Name the on-call receivers, the escalation path and who owns silences during planned upgrades of APISIX, so the first alert does not reach an unowned inbox.

Size and secure local storage

Prometheus stores samples in a local time series database with a default retention of 15 days, and local storage is not clustered or replicated. Decide how long you need gateway metrics for capacity reviews and incident analysis, and whether a remote write target will hold longer history. Plan disk for the chosen retention, back up the data directory, and confirm who can query the server. Ask your storage team to confirm the disk class and snapshot policy before go-live.

Configure the scrape, verify targets and load alert rules

This sequence takes the gateway from a disabled metrics output to a Prometheus instance that scrapes every APISIX node, evaluates alert rules and delivers alerts to each Alertmanager. Each step closes with a check you can run, so a fault is found before the next step begins.

Enable the APISIX metrics output
Your platform team enables the prometheus plugin in the APISIX configuration for your deployment mode. For traditional and decoupled deployments, this is the plugin list in conf/config.yaml. For standalone mode, use the configuration source your deployment reads. Confirm the option names, metrics listener and attributes against the documentation for your APISIX version in the deployment modes documentation. Restart or reload the gateway through your normal change process. The step is done when the gateway starts with no configuration errors in its error log.
Confirm the endpoint from the Prometheus host
Run the request from the Prometheus host, not from the gateway itself, so you test the same network path Prometheus will use. Use the address, port and path your APISIX version documents for the prometheus plugin, for example curl -s http://<apisix-host>:<metrics-port><metrics-path> | head. The response should be plain text in the Prometheus exposition format, with HELP and TYPE comment lines followed by samples. If the request times out, check the listener bind address, host firewall rules and security groups. The step is done when the output lists metric families for the gateway.
Add the APISIX scrape job
Add a scrape_configs entry to prometheus.yml. For a fixed set of gateway nodes, list each address under static_configs. For gateways running as Kubernetes pods, use kubernetes_sd_configs with relabeling to keep only the metrics port your version exposes. Give the job a stable name such as apisix so queries, dashboards and alerts stay readable. Set the scrape interval your team has agreed. Validate the file with promtool check config before reloading Prometheus. The step is done when promtool reports the configuration as valid.
Confirm each target is up
Reload Prometheus and open the Targets page under Status. Each gateway instance should appear under your job with the state UP and no scrape error. If a target shows DOWN, read the error text beside it, which usually names a connection or HTTP status problem, then fix the network path or endpoint and reload. Confirm the same thing from the query side by running up{job=\"apisix\"} in the expression browser. Each instance should return a value of 1. The step is done when every expected gateway node returns 1.
Query APISIX series in PromQL
Run queries against the gateway metrics to confirm that samples are being stored, not only scraped. Start with a selector filtered by the job label, then narrow to the metric families your version exposes for HTTP requests and upstream latency. Check each metric name against the endpoint output from the second step before you rely on it. Save the working queries with the team so dashboards and alert rules use the same names. The step is done when the queries return series for every gateway instance.
Load the gateway alert rules
Write a rule file with alerting rules for gateway health, such as a scrape target going down, and error rates or latency on the metric families you verified in the previous step. Add the file path under rule_files in prometheus.yml, validate it with promtool check rules, then reload Prometheus. Open Status and then Rules to confirm each group loaded. Set thresholds with the owners of the routes they protect. The step is done when each rule group appears with a health value of ok and no load error.
Point Prometheus at every Alertmanager
In the alerting section of prometheus.yml, list every Alertmanager instance under alertmanagers using static configuration or service discovery. Prometheus should send alerts to each instance directly, so do not place a load balancer in front of them. Cluster deduplication and routing depend on this setup, which is described in the Alertmanager documentation. Check the Alertmanagers page under Status, which should list each instance as active. Trigger a short test alert and confirm it reaches your receiver. The step is done when every instance is active and the test notification is delivered.

Which APISIX metric families matter for gateway health

The first decision is which metric families your dashboards and alerts will depend on. For a gateway, four families usually matter: HTTP request metrics for what clients see, upstream metrics for what your services do behind the gateway, stream metrics for TCP and UDP proxying, and LLM metrics where AI gateway plugins are in use. HTTP request metrics show traffic volume, response status and latency at the gateway edge. Upstream metrics separate a gateway problem from a backend problem, which is the distinction most incident reviews need. Stream metrics only matter if you proxy non-HTTP traffic, and LLM metrics only matter if an AI gateway plugin is actually routing model calls. Decide which families apply to your estate before you commit to alert thresholds.

The exact metric names, label sets and default behavior must come from the APISIX documentation for the version you deploy, not from memory or from older blog posts. Confirm which families are enabled in your configuration, including whether the Prometheus plugin is active on the routes and global settings you expect and which metrics endpoint and port your deployment exposes. Check what each family is labeled by, because labels decide both how useful a dashboard is and how many time series Prometheus must store. Ask your platform owner to record the confirmed list of families and labels in the runbook, so that alert rules and dashboards are built against a known set rather than against assumptions about a metric that may be absent or renamed after an upgrade.

Once the families are confirmed, pick a small set of gateway health signals for the first alert rules: request error rate by route, upstream error or timeout rate, and latency at the gateway compared with latency at the upstream. Add stream or LLM signals only when those traffic types are in production. Test each rule against real traffic before relying on it, and treat a metric that stops reporting as a finding in its own right, since a silent gateway can look healthy on a dashboard. Plan a review of this list after each APISIX upgrade, because metric additions and changes are expected between releases.

Controlling label cardinality in APISIX metrics

Route-level labels show which configured route produced a metric. They are usually the most useful dimension for gateway health because routes are deliberate configuration objects that change slowly. The number of series they create grows with the number of routes, and your team controls that number through configuration review.

Bounded by configuration: Route identifiers are set by administrators, so the label set grows only when someone adds or removes routes.
Strong for alerting: Error rates and latency per route show which service is degrading without reading individual requests.
Watch generated routes: If automation creates one route per tenant, environment or customer, series counts can multiply quickly. Confirm expected route counts with your platform team before enabling per-route dashboards.
Name routes deliberately: Stable route names keep dashboards and alert rules valid through redeployments and migrations.

Before you rely on route labels, estimate the route count for your largest environment, then confirm in the APISIX documentation for your version which route-level labels the prometheus plugin exposes.

Some labels should never reach the metrics store because their values are effectively unique for each request. Raw URIs with query strings, request IDs, client IP addresses and user identifiers fall into this group. The usual fix is to label by the route template or a normalized operation name, and to remove unbounded values before they are stored.

Drop request-scoped values: Request IDs, trace IDs and raw query strings belong in logs or traces, not in time series.
Normalize paths: Label by route template so that /orders/{id} is one series, not one series per order.
Relabel at scrape time: Prometheus supports metric_relabel_configs to remove or rewrite labels after scraping and before storage. Test these rules on a copy of the scrape configuration first.
Aggregate with recording rules: Recording rules can compute per-service or per-group series for dashboards, so detailed series can be kept short-lived.

Dropping labels at Prometheus does not reduce the work the gateway does to produce them, so also check the APISIX configuration for the metrics it exposes. Confirm the exact behavior with the Prometheus relabeling documentation for your version.

Each unique combination of metric name and label values is a separate time series. Prometheus keeps recent series in memory and writes samples to its local database, so more series means more memory use, more disk and slower queries. The Prometheus storage documentation also notes that local storage is not clustered or replicated, so growth lands on a single node that you must size and manage.

Dynamic path segments: Values such as order numbers or session tokens create a new series for nearly every request.
Client identifiers: Consumer keys, device IDs and tenant identifiers multiply series with each new value.
Memory pressure: Active series occupy memory even when they receive few samples, so a churn spike can stress the server.
Remote write amplification: Sending high-cardinality series to long-term storage increases ingest and storage charges in that system.

Monitor the number of active series on the Prometheus server, and set a sample_limit on the APISIX scrape job so that a misconfiguration fails visibly instead of silently filling storage. Confirm the limit behavior and the recommended series budget for your Prometheus version with your operations team.

Alerts that signal gateway health

A short list of alert categories covers the failures that matter most at the gateway. Each one should be tuned against the team's own traffic baseline, then routed through Alertmanager so one incident does not page the same people many times.

Target down

Prometheus raises a target down condition when a scrape of an APISIX instance fails, which usually means the process, its metrics port or the network path is broken. Check the up series per instance, not only the aggregate, so a single failed node in a pool stays visible. Confirm which metrics endpoint and port your deployment exposes before writing the rule, because a wrong port looks identical to a dead node.

Elevated upstream error rate

Alert on the share of requests that return upstream 5xx responses over a sustained window, not on a raw count, because the count grows with traffic. Split the rule by route or service where your labels allow it, so a fault in one backend does not hide inside a healthy total. Compare the threshold with the error rate your services normally show before you set it.

Latency growth

Track request latency percentiles per route and alert when a high percentile rises above its own recent baseline for a sustained period. Latency often climbs before errors appear, so this rule gives earlier warning of an overloaded upstream or a slow plugin. Set the baseline per time of day, since peak and off-peak traffic differ on most gateways.

Configuration sync and etcd concerns

In traditional and decoupled modes, APISIX depends on etcd for configuration, so a gateway that cannot reach etcd may keep serving stale routes without any client error. Alert on etcd connectivity and on configuration changes that fail to apply, and confirm with your own environment how each data plane reports sync problems. In decoupled mode, check every data plane, since one node can drift while the others update.

Silences and inhibition for noise control

Alertmanager groups related alerts into one notification, and inhibition suppresses symptoms when a root cause is already firing, such as latency alerts during a target outage. Use silences for planned maintenance windows, and make each silence expire on its own rather than staying open. Review the routing tree after each change to confirm that critical gateway alerts still reach the on-call team.

Mapping APISIX scrape targets and labels to Prometheus

This table maps each APISIX element to the Prometheus job and target it belongs to, the labels to keep, and the alert or dashboard that reads it. Metric and label names vary by plugin and release, so confirm each one in the APISIX documentation for your deployed version before writing a rule. The main takeaway is that the metrics endpoint is the only scrape target, and every other element reaches Prometheus as labels on that endpoint.

APISIX element	Prometheus job and target	Labels to keep	Alert or dashboard use
Client listener (port 9080 in traditional mode)	No scrape job. Client traffic is not a metrics source.	None from this listener	External reachability probe, kept separate from Prometheus metrics
Admin API (port 9180 in traditional mode)	No scrape job. Do not expose it to the scrape network.	None	No dashboard. Restrict access and monitor configuration changes through audit logs
Metrics endpoint (port set in your APISIX configuration)	Job for APISIX, one target per gateway instance	job and instance, set by Prometheus at scrape time	Alert when the target is down (up equals 0). Base dashboard panel for gateway health
Upstream	Same job, read from the metrics the gateway exposes per upstream	Upstream identifier, confirmed in the plugin docs for your version	Upstream error and latency panels. Alert on sustained errors for a critical upstream
Route	Same job, route-level series from the metrics endpoint	Route identifier only for critical routes, to limit cardinality	Per-route error ratio for business-critical APIs. Avoid alerting on every route
Stream route (TCP and UDP)	Same job, if stream metrics are exposed in your version	Stream route identifier, confirmed before use	Connection failure panel. Confirm availability before building an alert
LLM route (AI gateway)	Same job, LLM metrics from the AI gateway plugins, if enabled	Provider and model labels, confirmed in the plugin docs. No per-user labels	Token usage and latency per provider. Alert on sustained failover events

Securing the metrics path

Metrics expose traffic volumes, route names, upstream addresses and error patterns, so the path from APISIX to Prometheus and from Prometheus to its users needs the same care as the gateway itself. The cards below cover the network boundary, the Admin API, transport security, and Prometheus's own access model. Each control depends on your deployment and must be confirmed in your environment before you rely on it.

Restrict the metrics endpoint to Prometheus

The APISIX Prometheus plugin serves metrics on a separate endpoint from client traffic, and that endpoint should be reachable only from the Prometheus servers or the scrape pods that query it. Confirm the metrics listen address and port in your APISIX configuration, then check with a request from outside the allowed network that it is refused. Also confirm that load balancers and ingress rules do not publish that port to the internet or to general application networks. Metrics are not public data.

Keep the Admin API away from scrapers

The Admin API listens on port 9180 in traditional mode, according to the deployment modes documentation. Prometheus has no reason to reach it, and a scrape job that targets that port would expose the configuration interface to a monitoring network. Review scrape configs and firewall rules so that only the metrics port is allowed from the monitoring tier, and confirm that the Admin API is bound to management addresses only. Restricting it is a separate hardening task covered on the security hardening page.

Encrypt and authenticate scrape traffic

Scrape traffic can carry route names, consumer labels and upstream details, so decide whether it crosses only a trusted private network or needs TLS. Check whether your APISIX version and Prometheus plugin settings support TLS or credentials on the metrics endpoint, and whether your Prometheus version can present a client certificate or bearer token in its scrape configuration. Where a control is not supported, document the network segment that substitutes for it and record that decision.

Lock down the Prometheus web interface and API

Prometheus has no built-in user management, so its web UI and HTTP API are open to anyone who can reach them unless a proxy or network control stops them. Follow the project's security model guidance: place the server behind an authenticating reverse proxy or inside a private network, limit who can query the API, and restrict who can reload configuration or use administrative endpoints. Confirm these settings with the Prometheus security model page and your own access tests.

Protect Alertmanager and remote storage paths

Alerts and remote write traffic move data out of the Prometheus server, so the paths to Alertmanager and any long-term storage system need their own access controls. Confirm which hosts Prometheus sends alerts to, whether those connections use TLS and credentials, and which identities may write to or read from remote storage. Review these paths during the same access review as the scrape paths, because a permissive remote write target can leak the same metric data.

Common Prometheus scrape failures with APISIX

This table lists common scrape and alerting failures when connecting APISIX to Prometheus. Each row names a likely cause and the first fix to check. The main takeaway is that most gaps come from ports, label design, version drift or alert routing, and each can be verified in Prometheus before an incident.

Failure	Cause	Fix
Target down from firewall or wrong port	A network policy, security group or host firewall blocks the scrape, or the job points at the client port 9080 or the Admin API port 9180.	Confirm the metrics port in the prometheus plugin settings, allow Prometheus to reach it, then check the target error on the Prometheus targets page.
Metrics missing because a family is not enabled	Some series appear only when the related plugin or setting is on for a route, so expected names never show up in scrapes.	Compare exported names with the metrics documentation for your APISIX version, enable what is missing, then query again after a scrape.
Label explosion from client-specific values	Per-client values such as IP addresses, user IDs or raw URIs become labels, and each unique value adds a new series.	Keep labels to bounded values such as route, service and status, drop others with metric_relabel_configs, and watch head series in Prometheus.
Empty dashboards after a version change	Metric or label names changed between APISIX releases, so dashboards and alert rules query series that no longer exist.	Read the release notes for the target version, test a scrape in staging, and update dashboards and rules in the same change.
Alerts not firing because Prometheus points at a load balancer	Prometheus sends alerts through a load balancer, so each alert reaches one Alertmanager and cluster state splits.	List every Alertmanager instance in the Prometheus alerting config, set up Alertmanager clustering, and test with a sample alert.

Running Prometheus for the gateway over time

Plan the Prometheus server that scrapes APISIX as a stateful system with its own retention, storage and upgrade schedule, because the gateway dashboards and alerts are only as good as the history behind them. Prometheus stores samples in a local time series database organized into two-hour blocks, with a write-ahead log in front of them. The default retention is 15 days, and you can set it by time or by size. Decide how much history your incident reviews and capacity planning need, then set the retention flags to match and confirm the disk sizing against your own series count and scrape interval, since those numbers come from your environment rather than from a generic estimate.

Local storage is not clustered or replicated. The Prometheus storage documentation says to manage it like any other single-node database, so the plan needs a backup approach, a disk alert and a recovery procedure. If you need longer retention or a copy of the gateway metrics outside one server, use remote write to send samples to an external long-term storage system. Confirm which backend your organization already operates, what it costs to run, and whether it supports the query and alerting workflow your team uses. Remote write adds a second system to secure and operate, so write its ownership into the runbook before the first production scrape.

Schedule Prometheus upgrades against its release cycle. A new minor release cycle begins every 6 weeks, and a minor release generally stops receiving bug fixes after those 6 weeks, so a team that runs a minor version unchanged for long will run unpatched software. Long-term support releases receive bug fixes for one year. The release cycle page lists the current LTS line as 3.13, supported until July 31, 2027, and the GitHub releases page lists LTS patch releases. Pick a line your team can keep current, test each upgrade against your alert rules and recording rules, and confirm the support end date on the release cycle page before each planning cycle.

Questions buyers ask about APISIX Prometheus monitoring

What drives the cost of monitoring APISIX with Prometheus?

The cost comes from infrastructure, storage, implementation and the people who run the system, because Prometheus itself is licensed under Apache-2.0 and has no paid enterprise edition. Infrastructure covers the Prometheus servers, Alertmanager instances and any long-term storage you add through remote write. Storage grows with the number of active series, scrape interval and retention period, and the default local retention is 15 days. Implementation is a one-time cost covering scrape configuration, dashboards, alert rules and routing. Ongoing cost is the operating effort for upgrades, capacity checks and alert tuning. Ask any partner to split the quote into these components so you can see which parts you would carry yourself.

How long does an APISIX Prometheus monitoring project take?

Duration depends on your environment, and the agreed timeline is set in the written scope before work starts. The main variables are how many APISIX nodes and upstream services you run, whether Prometheus and Alertmanager already exist, how many teams need dashboards, and how quickly alert routing contacts can confirm escalation paths. A single-cluster setup with existing Prometheus infrastructure takes less effort than a multi-site estate that needs high availability for Alertmanager and remote storage. Ask for the timeline as a list of phases with the client dependencies named in each phase.

What does your team need to provide for this work?

The work needs access to the APISIX configuration so the metrics endpoint and plugin settings can be checked, access to the Prometheus hosts or the platform that runs them, and a named contact for alert routing. Alert routing needs people who can confirm which on-call rotation receives gateway alerts and which channels, such as email, chat or paging, should be used. You also need a non-production APISIX environment for testing scrape settings and alert rules before they reach production. Agree these access requirements and owners in the written scope so delays do not surface during the build.

Can our own team set up APISIX Prometheus monitoring without a partner?

Yes, a team with Prometheus and APISIX experience can do this alone, using the project documentation and a test environment. The steps are to expose the APISIX metrics endpoint, add a scrape job, confirm series appear, write alert rules for gateway health, and configure Alertmanager with grouping and silences. The harder parts are controlling label cardinality, sizing storage, and setting up Alertmanager for high availability, where Prometheus should point at every Alertmanager instance rather than a load balancer. A partner is most useful when the team lacks time or experience with these areas, or when the monitoring must fit an existing compliance evidence process.

Which parts of APISIX Prometheus monitoring cause problems later?

The most common problems come from high label cardinality, unbounded local storage and unrouted alerts. Labels that include request paths, client identifiers or other unbounded values can multiply the number of series and degrade query performance. Local Prometheus storage is not clustered or replicated, so a host failure means a gap in history unless you plan for it. Alerts that reach no one, or that fire constantly, are also common. Prometheus values reliability over precision, so it is not suited to per-request billing or any use that needs every event counted exactly. Ask whether the design includes cardinality limits and an alert review cycle.

Does DeployOpen provide compliance evidence for monitoring controls?

DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. For monitoring, that can mean documenting which gateway metrics are collected, how alerts are routed and reviewed, how retention is configured, and how access to the monitoring stack is limited. Independent auditors and certification bodies decide whether those controls meet a given framework. Ask the auditor for the evidence they expect before the build begins so the design produces it.

How do we keep Prometheus and Alertmanager current after launch?

Plan for regular upgrades, because a new Prometheus minor release cycle begins every 6 weeks and a minor release generally stops receiving bug fixes after those 6 weeks. If you need a longer support window, the long-term support line receives bug fixes for one year, and the current LTS line is 3.13, supported until July 31, 2027, according to the Prometheus release cycle page. Confirm which line your organization will run and who approves upgrades. Ongoing support, upgrades and continuous testing can be covered by a retainer, and the scope for that work is agreed in writing.

Is Prometheus a good fit for billing or exact request counts?

Prometheus is not the right tool where 100% accuracy is required, such as per-request billing. Its documentation says it values reliability over precision, and scrapes sample metrics rather than recording every event. For usage-based billing or audit-grade request logs, use a dedicated logging or metering pipeline and keep Prometheus for health signals like error rates, latency and upstream status. Confirm this split during scoping so the monitoring design does not become the source of billing data.

How DeployOpen scopes and supports APISIX monitoring

DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, including Apache APISIX monitoring with Prometheus. Engagements are fixed-scope, so the metrics, labels, alert rules and handover are agreed in writing before the build starts.

How we scope

Inventory which APISIX deployment mode and metrics endpoints your gateways expose before choosing scrape targets.
Agree which HTTP, upstream, stream and LLM metric families matter for your dashboards and alerts.
Set label cardinality limits, retention targets and remote storage needs in the written scope.

How we build

Configure Prometheus scrape jobs, service discovery and relabeling for every APISIX node in your estate.
Write and test alert rules for gateway health, upstream failures and scrape gaps against your thresholds.
Wire Alertmanager with grouping, inhibition and silences, pointing Prometheus at every Alertmanager instance.

How we hand over

Deliver the scrape configuration, alert rules and dashboards as versioned files in your repository.
Document metric meanings, label policies, retention settings and the steps to add a new gateway.
Run a walkthrough with your operators covering failure modes such as a single Prometheus outage.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover.
Track Prometheus release and long-term support status so your team knows when to plan an upgrade.
Review alert noise and cardinality growth with your team as traffic and route counts change.