cloudflare_worker_errors_count{status="exceededMemory"} disappears

[MarcoSaba]

We observed that the metric:

cloudflare_worker_errors_count{status="exceededMemory"}

was previously exported correctly, then suddenly disappeared for multiple days, and later reappeared again without any configuration changes.

This seems to correlate with a Cloudflare API error logged by the exporter.

We had alerts based on:

increase(cloudflare_worker_errors_count{status="exceededMemory"}[15m])

but suddenly the alert started returning no data. When checking directly in Prometheus / Thanos:

count(cloudflare_worker_errors_count{status="exceededMemory"}) returned no data.

However: count by (status) (cloudflare_worker_errors_count) returned:

{status="clientDisconnected"} 1
{status="success"} 1

So the metric family still existed, but the exceededMemory label value disappeared completely. We checked the exporter directly:

curl http://localhost:8080/metrics | grep cloudflare_worker_errors_count

Output:

# HELP cloudflare_worker_errors_count Number of errors by script name
# TYPE cloudflare_worker_errors_count counter
cloudflare_worker_errors_count{account="kestra",script_name="docs",status="clientDisconnected"} 0
cloudflare_worker_errors_count{account="kestra",script_name="docs",status="success"} 0

The status="exceededMemory" series was not present at all. So this is not a Prometheus issue — the exporter was not exposing it anymore.

We also have a suspicious log entry:

level=fatal msg="Error fetching zones: could not read response body: unexpected EOF"

After this error the exporter continued running and logging Filtering zone: ...

But it never exported exceededMemory again. The metric only reappeared days later, without any configuration change.

Observations:

• The exporter did not crash permanently
• It did not log additional errors
• No warning was logged about missing worker error statuses

Environment:
Helm chart: cloudflare-exporter-0.2.3
Image tag: 0.2.3
Deployed via ArgoCD
Kubernetes (GKE)
LOG_LEVEL=debug
Cloudflare zones configured via CF_ZONES

[WessnerVinicius]

We are also experiencing the same behavior in production (EKS, Helm chart 0.2.3).

The exporter restarts due to log.Fatal() when the Cloudflare GraphQL API returns transient errors such as:

time="2026-02-18 12:28:28" level=error msg="graphql: Internal server error"
time="2026-02-18 14:03:28" level=error msg="decoding response: invalid character 'u' looking for beginning of value"
time="2026-02-18 14:06:28" level=fatal msg="could not read response body: unexpected EOF"
time="2026-02-18 14:06:29" level=info msg="Beginning to serve metrics on :8080/metrics"

This causes the process to exit with code 1 and Kubernetes restarts the pod.

The issue seems to be that transient upstream errors are treated as fatal instead of recoverable.

We can confirm this is not related to CPU/memory/OOM, it is explicitly caused by log.Fatal().

We can provide additional logs if needed.

Do you think this could be related to Cloudflare GraphQL rate limiting or temporary upstream throttling?

In some cases we see responses that look like HTML (e.g. invalid character '<' looking for beginning of value), which suggests the API might be returning an error page instead of JSON.

As a mitigation step on our side, we plan to increase the Prometheus scrape interval to reduce request frequency and monitor whether the restarts decrease.

[MarcoSaba]

I confirm that I also experience frequent restarts of the pod.