Richer native Prometheus metrics: full exporter coverage, run timing, worker/queue metrics

Another useful metric would be the amount of stacks that are using a certain vendor (Terraform, OpenTofu, CloudFormation, Ansible, …).

To expand on the above, with Atlantis (which we’re moving away from), the prometheus metrics include things like Terraform version, repository, success/failure, time spent on init vs. plan vs. apply phases - all of which lets us run various analyses to understand how we use Atlantis (and is how we were able to analyze our Atlantis usage to map to # of Spacelift workers needed)

We’ve merged several closely related requests into this one so votes and discussion live in one place. The consolidated ask, as we understand it: a first-class native Prometheus/OpenMetrics endpoint (or exporter v2) with coverage at least at parity with the Datadog integration, documented, and efficient enough to scrape frequently. Specific metric families requested across the merged posts:

Run lifecycle: end-to-end run duration histograms (p50/p90/p99) with labels for stack, space, run type, terminal state; runs by state/type; unconfirmed/retryable runs; drift detection runs.

Worker pools: busy/idle workers, queue length (gauge), per-run worker wait time (histogram), utilization over time.

Stacks and governance: stack states (failed, drifted, locked, disabled), vendor and tool-version usage across stacks.

Exporter mechanics: full coverage of the metrics API, adjustable histogram buckets, docs for every metric.

This maps to the observability improvements we have referenced on our roadmap. Keep voting and add missing metrics in the comments; specifics here directly shape scope.

This is a really demanded feature that we've been tracking for quite some time. I've got good news to share with you all.

v0.12.0 is a prerelease build. We are looking for feedback before making it official, so if you hit a bug, a regression, or a metric that looks wrong, please open an issue at https://github.com/spacelift-io/prometheus-exporter/issues.

If you monitor Spacelift with Prometheus, this release makes the exporter faster, more transparent about what it is doing, and easier to tune to your account.

Missing metrics are back. spacelift_worker_pool_workers and spacelift_scrape_duration_seconds were defined but never exposed. Both now show up on the /metrics endpoint.

Scrapes run concurrently. Collectors used to query the Spacelift API one after another, so a slow endpoint held up everything. They now run in parallel, which cuts total scrape time and lowers the risk of Prometheus timeouts on larger accounts.

Per-collector health. Each collector now reports its own success status and request duration. When a scrape degrades, you can see which collector is slow or failing instead of guessing from a single aggregate number.

Partial scrapes, opt in. Previously, one failing collector failed the whole scrape and you lost every metric. You can now opt into partial scrapes so healthy collectors keep reporting while the broken one is flagged. Collectors that hit features your account does not have are marked unsupported rather than failed, so they stop generating noise.

Turn collectors on and off. New --collector.<name> and --no-collector.<name> flags let you disable collectors you do not need. Fewer API calls, faster scrapes, and no metrics you never look at.

Under the hood. Each collector now issues a single named GraphQL operation, which makes API-side tracing and debugging easier. The project also gained a collector test harness with golden metric snapshots, so metric names and labels are locked down against accidental changes. Dependencies were bumped, including prometheus/client_golang 1.24.1 and urfave/cli v3.12.0.

Thanks to first-time contributors @aerfio and @jkowall.

Full release notes and binaries: https://github.com/spacelift-io/prometheus-exporter/releases/tag/v0.12.0

I’d really appreciate if this topic could be revisited and given higher priority.

While exploring the GraphQL API, I confirmed there is already enough high-value data available today to expose much richer Prometheus metrics without guesswork. I documented a realistic set of candidate metrics covering:

• Vendor & tool usage (Terraform vs OpenTofu, Terragrunt usage and versions)

• Stack state & governance signals (disabled, blocked, locked, protected from deletion, drifted)

• Run lifecycle signals (runs by state/type, unconfirmed runs, retryable runs, drift detection runs, run lag)

• Worker pool signals (users, limits, management model)

These metrics would directly address the gaps mentioned in this thread and unlock better capacity planning, adoption tracking, and operational visibility for teams using Prometheus and Grafana.

Given that the API already exposes the underlying data, I believe prioritizing this would deliver significant value to many customers.