Is the metric label actions_github_com_scale_set_name requirement in the demo dashboard accurate?

[GlacierWalrus]

Why are you starting this discussion?

Question

What GitHub Actions topic or product is this about?

Metrics & Insights

Discussion Details

In this example dashboard document, you stipulate some required labels.

I don't see references to actions_github_com_scale_set_name in the helm chart values nor anywhere else.

Is this something you expect users to attach at metric-ingestion time? Strikes me as an odd name for a user-provided label.

[nocturne1]

I got clarification on this here: https://github.com/orgs/community/discussions/160451#discussioncomment-13005956
It requires prometheus scraping changes.

[GlacierWalrus]

Thank you, that's exactly the confirmation I was searching for.

I think that (given this is both a github application their own docs) the page I linked to is too ambiguous for that to be obvious.

There's also quite a disconnect between the helm charts and this required configuration. You'd think they might want to call our those labels, or automatically configure + export them, given the releases "know" the values of those labels already.

[Stefina-11]

1. Update Documentation
   
   2.Adjust Dashboard Queries
   If the Grafana dashboard enforces this label, update queries to:
   
   3.Merge & Notify
   Submit a PR, tag @GlacierWalrus, and close the issue post-merge.
   Impact: Eliminates confusion with zero functional changes. Time: <1 hour.

[Praveen23-kk]

irst, we're going to update our documentation. Basically, it seems we're changing the name of something or standardizing a label. We just need to go into our guides and wikis and make sure the text reflects this new standard. This way, nobody gets confused by the old information.
Second, we need to tweak our monitoring dashboards. You know all those charts and graphs we use in Grafana to see how things are running? Some of them are built to only look for data with a specific tag (or 'label'). We need to update the "question" the chart asks our system, so it looks for the new label instead of the old one. If we don't, the charts might go blank or show errors, so this is an important little fix.
Finally, we'll get it approved and wrap it all up. Once you've made the changes:
Submit a "Pull Request" (PR). This is just our formal way of asking someone to review your changes before they go live.
Tag GlacierWalrus in it. Just type @GlacierWalrus in the PR description. This sends them a notification so they know to take a look.
Once they approve it and your work is merged, you can close the ticket. That tells the whole team the job is officially done.
The main takeaway is that we're not changing how anything actually works. We're just fixing some confusing names to make life easier for everyone. It should be super fast, less than an hour of work."

[RManasvi]

@GlacierWalrus I've encountered this as well and just wanted to contribute to the discussion.

It's certainly perplexing that actions_github_com_scale_set_name is a required field in the dashboard with no explanation of how or where it's being set within the Helm chart. I also didn't see it referenced in the values.yaml or within the Prometheus job configs themselves.

Upon reading @nocturne1's response and diving into it, I concur: the label must be applied manually during Prometheus scraping, usually through relabel_configs. That should most likely be spelled out more explicitly in the docs or auto-exported by the Helm chart, as the label values are already known at deployment time.

It'd be nice if the dashboard either gracefully dealt with the lack of this label or the chart exported it automatically.

[Priyanshuchauhan17]

Internal or Legacy Artifact:
It might be an internal label used by the platform's backend, or a legacy artifact that was never cleaned up. Sometimes systems retain older naming conventions that no longer apply to user configurations.

[W-N-R]

Ensure your documentation reflects the latest run timestamps (e.g., current attempt) for accurate metrics.
Preferred Fix: Update the webhook documentation to explicitly state that created at and started at retain the original run times, while current attempt should be used for rerun tracking.
Optional Adjustment: If consistent timestamps are critical, consider calculating real run durations (e.g., using current attempt - started at) and adjusting downstream systems accordingly.

[Dasmat13]

Hey folks,

I'm going through the example dashboard doc, and I noticed that it mentions a required label: actions_github_com_scale_set_name.

I couldn’t find this label anywhere in the Helm chart values or other parts of the documentation. Is this something we're supposed to manually attach when ingesting metrics? It feels like an oddly specific name for something a user would provide — sounds more like something that might be auto-injected by GitHub or some internal infrastructure.

Just trying to understand whether this is required in self-hosted setups, or if it's safe to ignore/remove it from the example if it's not relevant to our deployment.

Appreciate any clarification!

Thanks!

[BiodunDevv]

The confusion around actions_github_com_scale_set_name seems to stem from a mismatch between the example dashboard expectations and what's actually exposed in self-hosted deployments.

Recommended Fixes:

1. Update Documentation:
   Clarify that this label is only auto-populated in GitHub-hosted environments. For self-hosted setups, it should be manually injected via Prometheus relabel_configs, or else removed from the dashboard queries to avoid filtering out valid data.

2. Adjust Dashboard Queries:
   If dashboards are filtering on this label, we should either:

   Remove the filter, or

   Wrap it in a conditional using label_replace or label_exists() (depending on Grafana version) to ensure queries don’t fail when the label is missing.

3. Standardize Label Behavior:
   Ideally, the Helm chart could be updated to expose this label as a configurable value — allowing users to explicitly define it if needed, or omit it cleanly.

4. PR & Tag:
   Once the docs and dashboard queries are updated, submit a PR and tag @GlacierWalrus for review. This avoids future confusion, especially for those new to GitHub Actions metrics and Prometheus.

Let me know if a sample relabel_configs block or dashboard patch would help — happy to contribute.

[abinasharma001]

You're absolutely right to question that — actions_github_com_scale_set_name is not a default label exposed by GitHub-hosted runners or standard Helm chart configurations. It's also not something you’ll find directly in the chart values.

This label is most likely intended for setups using self-hosted runners in autoscaled environments, such as:

• Kubernetes-managed GitHub runner deployments
• Dynamic runner pools or scale sets defined through custom infrastructure

In those cases, this label is expected to be manually attached during metric ingestion, for example:

• As a relabel config in Prometheus
• Injected via exporters or sidecars
• Passed through in ingestion pipelines (e.g., with OpenTelemetry or custom Prometheus adapters)

The purpose is to tag metrics with a runner pool or scale set name, allowing dashboards to group and filter data more effectively — especially in multi-tenant or enterprise-scale environments.

That said, I agree with your observation:
The name actions_github_com_scale_set_name is quite specific and may be unclear to end-users. Something more generic like runner_pool, scale_group, or infrastructure_group might make it easier for users to understand and configure.

[guidopastorino]

It did seem like actions_github_com_scale_set_name might have been an internal label from GitHub-hosted runners rather than something users are expected to provide. Since it’s not referenced in the Helm chart or ingestion pipeline, I just wanted to double-check whether it was an oversight or if we’re supposed to replicate that label ourselves.

Would it make sense to either:

Update the dashboard to remove the dependency on that label (if it’s not critical), or

Add a note in the documentation explaining how/when users should provide it (if needed)?

Happy to open a PR if a change is needed.

[HabibParvej]

actions_github_com_scale_set_name is not included by default in the Helm chart or exporter config.

It’s expected to be manually attached during metric ingestion, likely via Prometheus relabeling or a custom setup.

The label is likely used to identify scale sets in self-hosted runner environments.

It’s not mandatory unless your infrastructure requires that level of detail.

You can safely replace it with a more relevant label for your environment.

[SoftCoderPKumar]

Please clarify:

1. Which demo dashboard are you referring to?

• GitHub Actions self-hosted runners dashboard?

• Prometheus/Grafana monitoring demo?

• Some open-source project or internal demo?

2. Are you using a specific GitHub Actions runner autoscaler like actions-runner-controller, Arc, or a custom scaler?

3. Where do you see this metric/label? Is it:

• In a PromQL query?

• A panel in Grafana?

• A custom alert rule?

General Answer (assuming Prometheus + GitHub Actions + autoscaler):
If you're using GitHub Actions runners on Azure VMs with scale sets, a label like actions_github_com_scale_set_name could be attached to metrics to indicate which scale set is responsible for the runner.

• ✅ Accurate if: Your exporter or autoscaler attaches this label to runner metrics (e.g., runner online/offline state, job queue length).

• ❌ Not required: Unless your dashboard needs to differentiate between multiple scale sets, the label may not be strictly necessary.

• 🔍 In some cases, dashboards might include example label filters that need to be customized for your environment.

What You Should Check

• Inspect the metric in Prometheus UI (e.g. up{job="github-runner"}) — see if actions_github_com_scale_set_name appears in the label list.

• Check the Grafana panel queries for errors like “no data” — that often happens if a label is referenced but doesn’t exist in your setup.