Introduction

When Prometheus is "not scraping additional scrapes," the problem is rarely the scrape loop itself. In most cases, the extra job was never loaded, the target was dropped by relabeling, the target is down, or a config reload failed and Prometheus kept using the old configuration.

Start By Checking What Prometheus Actually Loaded

Do not debug YAML in the abstract. First confirm whether Prometheus is using the scrape config you think it is using.

Useful places to check are:

• the /targets page
• the /config page
• Prometheus logs
• the result of promtool check config

A minimal scrape job looks like this:

1global:
2  scrape_interval: 15s
3
4scrape_configs:
5  - job_name: app
6    static_configs:
7      - targets: ["app:8080"]

If your new job is missing from /config, the file was not reloaded or the wrong file was edited.

Reload Problems Are Common

Prometheus does not magically reread the configuration unless you restart it, send SIGHUP, or use the reload endpoint when lifecycle reload is enabled.

promtool check config /etc/prometheus/prometheus.yml
curl -X POST http://localhost:9090/-/reload

If the new config is invalid, Prometheus keeps the previous working configuration. That leads many teams to believe the "additional scrapes" were accepted when they were actually ignored.

Also verify that the process is using the file you edited. The active config path comes from the --config.file flag.

Target Discovery May Succeed But Relabeling May Drop It

Sometimes the target is discovered and then removed by relabeling rules.

1scrape_configs:
2  - job_name: app
3    static_configs:
4      - targets: ["app:8080"]
5    relabel_configs:
6      - source_labels: [__address__]
7        regex: ".*:9090"
8        action: keep

That configuration drops app:8080 because it only keeps targets ending in 9090.

If a target never appears in /targets, inspect relabel_configs and metric_relabel_configs separately. relabel_configs can remove the scrape target itself; metric_relabel_configs only affect scraped samples after the target has already been reached.

Timeouts, Intervals, And Bad Endpoints

A scrape job can exist and still collect nothing if the endpoint is not reachable or takes too long.

1scrape_configs:
2  - job_name: slow-app
3    scrape_interval: 30s
4    scrape_timeout: 10s
5    static_configs:
6      - targets: ["slow-app:8080"]

Practical checks:

curl http://slow-app:8080/metrics

If the endpoint hangs, returns an HTML error page, or requires authentication that Prometheus does not send, the job will show failures even though the configuration is present.

Also remember that scrape_timeout cannot exceed scrape_interval. Invalid combinations will fail validation.

Extra Config Files Need To Be Referenced Correctly

Some setups split scrape jobs across multiple files. In that case, changing an included file is not enough unless the main config references it correctly and reload behavior covers referenced files.

For example:

1scrape_configs:
2  - job_name: base
3    static_configs:
4      - targets: ["localhost:9090"]
5
6rule_files:
7  - "/etc/prometheus/rules/*.yml"

Notice that rule_files and scrape_configs are different concepts. Prometheus does not load extra scrape jobs from rule_files. If you are using a deployment-specific pattern such as mounted fragments or operator-managed additionalScrapeConfigs, verify that the final generated Prometheus configuration contains the expected job.

Kubernetes And Operator Setups Add Another Layer

In Kubernetes, teams often edit a Secret or Helm value and assume Prometheus picked it up. In operator-based setups, the real questions are:

• did the Secret update correctly
• did the Prometheus resource reference it correctly
• did the operator regenerate configuration
• did Prometheus reload the generated config

So if you use a Prometheus Operator or chart wrapper, debug both the generated Prometheus config and the higher-level Kubernetes objects.

Common Pitfalls

The most common mistake is editing a config file and forgetting to reload Prometheus.

Another common problem is validating only YAML syntax, not the actual scrape behavior. A syntactically correct job can still point to a dead endpoint.

Teams also confuse relabeling with scraping and accidentally drop targets before they ever appear.

Finally, in Kubernetes environments, the source of truth may be a Secret, ConfigMap, or custom resource rather than the file you are inspecting on disk.

Summary

• Check /config and /targets before guessing.
• Validate config with promtool and reload Prometheus explicitly.
• Inspect relabel rules if targets disappear.
• Test the metrics endpoint directly with curl.
• In Kubernetes, verify the generated config path, not only the higher-level manifest.