Actions Usage Metrics is generally available

[natalierjackson]

Actions Usage Metrics is now generally available for all GitHub Enterprise Cloud customers. Actions Usage Metrics enables you to view data about your Actions workflow runs throughout your organization.

You can use this data to identify opportunities to optimize your pipelines and reduce wasted runtime minutes which, when addressed, can lead to faster runs and increased developer productivity.

Actions Usage Metrics breaks down the utilization of workflows, jobs, source repositories, and operating systems for GitHub hosted runners and self-hosted runners. All of this data is available in the UI and can be exported and shared as a .csv file if you wish to integrate your usage data with internal or third party tools.

[geoffreywiseman]

Are there new API endpoints to get this data? I have a GH CLI extension for actions usage and the available information via API is pretty limited at the moment. ;)

[tonyjcamp]

No APIs yes, BUT they're are on our radar. Thank you for voicing your need for them!

[Aviputta1]

@geoffreywiseman may i know which CLI extension are you using to retrieve the actions usage metrics? could you please share the extension documentation. Thanks in Advance.

[geoffreywiseman]

@Aviputta1 The extension is https://github.com/codiform/gh-actions-usage (which effectively replaces https://github.com/geoffreywiseman/gh-actuse). They're pretty limited because the API backing them is pretty limited, which is why I was asking if this new data will have an API I can consume.

[jeffwilcox]

+1, this feature will be great once there's an API

[austinpray-mixpanel]

Yeah I'm interested in making a prometheus exporter for these metrics once there is an API 👍

[uwehdaub]

It seems that the data is nor consistent.
E.g. when I list e repo on the Repositories tab I get 11 workflows and 582 workflow runs.
When I list the same repo in the Workflows tab I get 15 workflows and a total of 754 WFRs.
But the total minutes match exactly.
This seems to be improvable.

[philip-gai]

👋🏼 Thank you @uwehdaub for the feedback!

The workflow count and workflow runs are different across the tabs because they are aggregated using different dimensions. The workflows tab breaks down the usage by runner type and runtime OS. The repository tab does not. So if Workflow A runs on Repo A and has 2 hosted jobs, job-linux which runs on linux and job-windows which runs on windows, on the repo tab that will count as 1 workflow and 1 run with, say, 100 total minutes. On the workflows tab there will be two different rows, one for Repo A + Workflow A + Hosted + Linux, and one for Repo A + Workflow A + Hosted + Windows , with 1 job and 1 workflow run counted on each row, and say 75 mins and 25 mins respectively. So the total workflows and workflow runs for Repo A on the repo tab will be 1, but the total on the workflows tab if you’re summing up the columns will be 2, but the total minutes will match.

[uwehdaub]

Thank you @philip-gai for the explanation.

I believe these kinds of explanation belongs to the documentation of the feature.
Otherwise more people will stumble on these "inconsistentcies".

[ChrisOwen273]

This would be very useful information to have access to via the API. Would be very interested to hear if this is something planned.

[tonyjcamp]

APIs are on our team's roadmap. Thanks for the feedback!

[TheDevMinerTV]

Now make it available for non-enterprise customers.

[lkfortuna]

this is now available to non-enterprise customers!

[sparker-dg]

Is there a summary report across all enterprise orgs, or are we going to have to assemble that manually. We have 40'ish orgs that are used across our enterprise, and it would be nice to have all this data in one place for back-billing charges to the departments.

[tonyjcamp]

Not today but it's something we're working towards. Based on your goal of assigning billing to departments, you'd still need some manual work because Usage Metrics is showing wall-clock minutes - that is, raw minutes without OS multipliers or large hosted runner premiums. So keep that in mind!

[sparker-dg]

Thanks! I appreciate the tip!

[astendal]

This is a great addition. +1 to previous comments on API support and enterprise-level visibility. Are there plans to break this down further and show invocations of shared workflows and actions? It'd be great to know how often reusable components are being consumed. Additionally, for the runners, it'd be good to know which labels are being invoked so we can distinguish between the different self hosted runners that users are referencing in our enterprise.

[lkfortuna]

hey there 👋 we do have it on our roadma to add labels. The reusable feedback is something we have heard but don't have any plans for atm. Thanks for the feedback!

[vmasek]

So sad this is only available for Enterprise tier, insights for actions are really missing compared to other cloud runners on the market

[philip-gai]

We have plans in the roadmap to open this up to a broader audience (not just enterprise), so stay tuned!

[lkfortuna]

this is now available for non-enterprise customers!

[Aviputta1]

Hello everyone,

As GitHub Enterprise Cloud customers, we're currently trying to pull usage data for GitHub Actions. I understand that the API currently does not support this functionality.

Our current method involves manually downloading reports from the UI, which is not ideal for our needs. We're looking for a more automated and streamlined approach.

Does anyone know of an alternative way to extract this data, perhaps through a third-party tool such as Splunk or similar? Any guidance or suggestions you could provide would be greatly appreciated.

[philip-gai]

We have plans in the roadmap to support an API for usage data, so stay tuned!

[Ugenx]

Any plans to support Github Enterprise Server?

[lkfortuna]

we do not have plans for Enterprise server at this time.

[vinaysandela]

The Metrics feature is great. We are looking for using it at Enterprise too. Would be really helpful. Thanks

[lkfortuna]

Thanks for the feedback, we do have it on our roadmap to add to enterprise level!

[chriscarpenter12]

Are the total minutes adjusted for the minute multiplier or are these the raw numbers?
https://docs.github.com/en/billing/managing-billing-for-your-products/managing-billing-for-github-actions/about-billing-for-github-actions#minute-multipliers

[philip-gai]

These are raw numbers!

[chriscarpenter12]

Thanks. Good to know as I wasn't sure. It would be nice if the minutes could be display also in relation to the billable minutes.

For instance on the default cloud 50k minutes it's hard to look at the list in relation to what's "used" if we get an alert saying we've used 75% of our allotment.

And filtering the workflows by runner type doesn't give a running total either if I wanted to see hosted only minutes.

Without an API we have to download the csv then manipulate the minutes by the multiplier the get an accurate total in relation to what repo/workflow is consuming the minutes.

[chriscarpenter12]

@philip-gai Didn't see it mentioned, but are you aware the exported csv has an extra single quote ' in the field wrapping?

Example """'string_value"""

Snippet from an export today

"""'Workflow""","""'Source repository""","""'Total minutes""","""'Workflow runs""","""'Jobs""","""'Runner type""","""'Runtime OS"""
"""'.github/workflows/test.yml""","""'test""",2416,437,1,"""'hosted""","""'linux"""

[philip-gai]

Yes we are aware and we will update the docs to reflect this. This is because we are now following the OWASP recommendations to avoiding CSV injection documented here.

[skorotygin]

Hello Everyone,

I wanted to share my experience here and I am looking for some help.

About two months ago I implemented data collection mechanism for GitHub Actions usage using Python. I intentionally do not want to go into too much details, but on a high level the algorithm looks like this:

1st step: since we are Enterprise and have multiple Orgs, I am first getting the list of all Orgs in the Enterprise.

2nd step: for every Org in the Enterprise, I am getting a complete list of Repos residing under the Org:

api_url = 'https://api.github.com/orgs/{}/repos?page={}&per_page={}'.format(org, page + 1, per_page)

3rd step: for every Repo under the Org, I am getting the list of all Workflows:

api_url = 'https://api.github.com/repos/{}/{}/actions/workflows'.format(org, repo)

4th step: for every Workflow in the Repo, I am getting the list of all Workflow runs on or after the certain date:

api_url = 'https://api.github.com/repos/{}/{}/actions/workflows/{}/runs?page={}&per_page={}'.format(org, repo, workflow_id, next_page, per_page)
response = requests.get(api_url, headers=headers, params=f"created=>={date}")

5th step: For every Workflow run I am getting usage metrics:

api_url = 'https://api.github.com/repos/{}/{}/actions/runs/{}/timing'.format(org_name, repo, run_id)

This code is implemented as a Google Cloud Function and runs every day, capturing the previous day activity.

I have run into some problems though.

1. We are large organization and have thousands of repos, so obviously I am making tenths of thousands of API calls and I did hit primary and secondary rate limits and had to solve for it. Collecting data using this method is extremely slow and takes a lot of time.
2. When I compare results obtained using my Python script with the report produced by GitHub, there are days when I do not have any differences at all and total minutes in my report do match exactly with total minutes on Github report, and there are days when I have very little discrepancies, literally 1, or 2, or few minutes. Typically it is just one repo out of several thousands.

Questions:

1. Would it be possible to convert this RestAPI logic into a GraphQL query?
2. Does anyone know why I am getting differences in few minutes on some days / some repos between my report and GitHub usage report?

Any help or advice would be greatly appreciated!

[michaeljs1990]

Do you have any plans to fix current issues with GitHub actions? Are you just in add new feature mode now while the product is severely lacking on several other areas?

1. How do you require a job to pass before it can be merged without setting everything to be required. Crazy thought but maybe some jobs don't need to run all the time which if you set a job as required it does otherwise you can never merge it.
2. Support at the very least folders so that in large repos you don't have 50+ workflow files in the same folder some of which are workflow_calls and others are actual actions.
3. All jobs on the merge queue should pass for a PR to be landed on main. Once again the silliness that is setting "required" jobs is such a bad design decisions I can't imagine the conversation that happened around letting that become a feature.

Would be great to see actual issues fixed but really cool metrics.... thanks.

[lkfortuna]

hey there - we do have specific feedback discussions for all of the topics you mention above. if you want to go and add your thoughts to those discussion that would be helpful for us when we go and aggregate how many customers want certain features!

[samus-aran]

A huge thank you to everyone who joined in on this discussion and shared your thoughts! Your feedback has been amazing, and we truly appreciate the time you’ve taken to contribute.

With Actions Performance Metrics now in Public Preview we’re going to close this thread so we can focus on a new conversation that dives into the latest updates. If you’d like to keep the conversation going (and we hope you do!), please jump over to the new thread and add your thoughts there. 👋

[Rymania]

I am interested at looking at the 'called' workflow usage so that we can measure reuse of our reusable actions and workflows. Right now I cannot see a way of doing this; the caller workflows and actions are displayed.

Example: a ci.yml workflow in a given repository calls:

• reuse-build.yml
• reuse-deploy.yml
• reuse-test.yml

As the owner of the 3 called workflows I am interested in usage of them, however they are hidden in the GitHub Actions Org Insights because they only show the usage of ci.yml for that given run.