Prometheus relabel tester — see what your rules do before they drop your metrics.

Both apply the exact same relabeling actions and semantics — the difference is only where they run in the pipeline. relabel_configs runs before a scrape, on the target labels coming from service discovery, and can keep or drop whole targets. metric_relabel_configs runs after a scrape, on every sample's label set, and is used to drop or rewrite individual time series. This tester handles both, so you can use it as a metric_relabel_configs tester or a relabel_configs tester interchangeably.

Paste a YAML list of relabel_configs in one pane and one or more sample label sets in the other, then hit Run. The relabel_configs simulator applies your rules exactly the way Prometheus does and shows the resulting labels, which were added, changed, or removed, and whether the target was dropped. It is the fastest way to test relabel_configs against sample labels online and confirm a rule behaves the way you think before you ship it to a live scrape config.

Almost always because the regex did not match — and the regex is fully anchored. Prometheus wraps every relabel regex as ^(?:your-regex)$, so the pattern must match the entire joined source value, not just part of it. A regex of api will NOT match a value of api-server. With a keep action, anything that fails to match is dropped, so the target silently disappears. Use this Prometheus relabel debugger to see exactly which value was joined and why the regex is not matching — then widen it with (.*) or explicit capture groups.

keep removes the target (or series) unless the joined source value matches the regex; drop removes it when it does match. They are mirror images — keep is an allow-list gate, drop is a deny-list gate. Both decide whether the series is scraped or stored at all, rather than rewriting a label. This Prometheus relabel keep/drop tester marks any dropped target with the rule and action responsible, so you can see which rule removed a series.

The default separator is a single semicolon (";"). When a rule lists more than one entry in source_labels, Prometheus joins their values with that separator before matching the regex — so source_labels: [job, instance] on job="api", instance="10.0.0.1:9090" produces api;10.0.0.1:9090. The tester uses the same default, so you can verify how multiple labels join (and write a regex that accounts for the ";") before applying it.

hashmod joins the source labels, takes the MD5 of the result (the same md5.Sum Prometheus uses), reads the last 8 bytes of that digest as a big-endian 64-bit integer, and stores hash % modulus in the target label. This Prometheus relabel hashmod tester reproduces that exact recipe, so the shard values it produces match Prometheus byte-for-byte. That lets you verify a horizontal-sharding setup — hashmod into a temporary label, then keep on the shard you own — before deploying it.

labelmap operates on label NAMES, not values. For every label whose name matches the regex, it copies that label's value into a new label named by the expanded replacement — the classic __meta_kubernetes_pod_label_(.+) to $1 move that promotes Kubernetes pod labels to plain labels. The Prometheus labelmap relabel tester runs it against the actual label names in your set, and also models labeldrop and labelkeep, which remove labels whose names match (or do not match) the regex.

No. This is an online Prometheus relabel_config tester with no install and no signup, and it runs 100% client-side. Your relabel rules and label sets are parsed and evaluated inside your browser tab — nothing is uploaded to a server. You can safely paste internal scrape configs, including private target metadata and label names. This tool is independent and not affiliated with, endorsed by, or sponsored by the Prometheus project or the Cloud Native Computing Foundation.