Exploring the New Actions Performance Metrics Now in Public Preview 👀⏱️

[samus-aran]

We are excited to introduce a new observability UI that provides insights into the performance of your workflows and jobs for your organizations or repositories, now available in public preview! Performance metrics are designed to help you monitor, analyze, and optimize your Actions workflows and job execution. With these insights, you can answer common questions like:

• How long does it take for my workflows or jobs to complete? Gain visibility into the end-to-end execution times of your workflows and jobs, helping you identify bottlenecks and areas for improvement.
• How long are my workflows or jobs waiting to run? View queue times to identify bottlenecks in job scheduling, enabling you to make adjustments that reduce idle time and improve throughput.
• Which of my workflows or jobs are consistently failing? Spot frequent failures in your workflows, pinpoint root causes, and take preemptive actions to improve reliability and performance.
• Where are my longest-running workflows or jobs originating from?
  Get insights on job origin points, allowing you to address lengthy processes directly and refine areas with the most significant impact.

Getting Started ➡️

To start leveraging these insights, navigate to your organization or repository homepage, select **“Insights” **near the top of the page, and then choose “Actions Performance Metrics” on the left side of the page. Once you’re there, you’ll have public preview access to detailed metrics on your workflows and jobs, offering a comprehensive view of performance at every stage.

GitHub Actions Metrics for Free, Pro, and Team plans 🆓

We are also pleased to announce that with today's release, GitHub Actions Metrics are now available to Free, Pro, and Team plans. Previously, this feature was only available to those on the GitHub Enterprise Cloud plan.

To learn more about GitHub Actions Metrics, check out our public documentation

Share your Feedback 💬

We’re committed to making Actions Performance metrics as helpful and actionable as possible, and hearing directly from you will guide future improvements. As you explore the new feature, keep these questions in mind to help guide your experience:

• Metrics or Data Points: Are there additional metrics or data points you’d like to see included? Are there metrics that could be more robust?
• Usability and Navigation: Is there anything about the layout or navigation that could be more intuitive?
• Troubleshooting Suggestions: Are there any tips or contextual insights you’d find helpful when reviewing your performance metrics, especially for identifying and resolving issues faster?

We'll use both discussions (Enterprise preview back in July ) to collate your feedback 👍

Share your Wins 🏅

We’d love to hear how you’re using the new Actions Performance Metrics to make a difference in your workflows and job management. Has this feature helped you identify and address issues you previously couldn’t pinpoint? What changes did you make, and what was the outcome? Did the insights reveal any surprises in your workflows, such as hidden bottlenecks or frequent failure points?

Share your stories and feedback in the comments below 👇👍

[giordano]

The dates in /actions/metrics/performance and /actions/metrics/usage are displayed in the weird format month/day/year, can we have the ISO 8601-approved format year-month-day, or at very least day/month/year? Thanks

Edit: it turns out my LANG env var was screwed up and was set to C.UTF-8 despite I had previously set the system to use a different locale. Resolving the issue also brought back a better display of the date on GitHub, which was clearly only using a system setting. Sorry for the noise!

[samus-aran]

weird format

I appreciate this comment, it made me chuckle 😅

[JamesBurnside]

Is there a way to filter by branch? I'd love to be able to filter the insights of my team's action runs by our main branch to determine stability and performance in scenarios where it should pass 100%

[philip-gai]

There is not a way to filter by branch currently. But this is interesting feedback, thank you!

[austinpray-mixpanel]

We monitor the same thing via Mixpanel right now. In addition to ability to filter by branch you also need ability to filter by event (push, workflow_dispatch, schedule, etc). GitHub Actions triggered via push to our default branch are expected to pass 100% of the time. Branches triggered via workflow_dispatch or on a schedule should definitely pass but they have a different SLA for us. Like a cron job that deletes stale branches failing is lower priority than a test suite failing in the default branch (all developers are blocked).

[mrmckeb]

We also need the ability to filter by branch, as we conditionally run/change steps depending on the branch and when in the merge queue.

[astendal]

This is a much-needed addition, thanks for your work on this. For an enterprise like ours with more than 100 organizations, this won't be very useful for administration until we can get an enterprise-level version of this dashboard.

That said, here's some additional views we'd love to see here (the most important ones to our enterprise are at the top):

• Summary (i.e, a fixed number) of current jobs in each state (queued, running, etc), filterable by runner group
• Graph of average and 95th percentile duration in each state, filterable by runner group
• Queue table per runner group
• Top N users and repositories by number of concurrent queued and running jobs (i.e, noisy neighbors)
• Execution duration by reusable component, e.g. "actions/checkout average run time: 15 seconds"

Some of this ☝️ is related to the feedback I left on the usage metrics discussion.

If you have API support in the pipeline sooner than an enterprise-level dashboard, we'd love to know so we can plan to cobble together our own enterprise-level summaries.

[philip-gai]

An enterprise-level dashboard and an API are both on our roadmap! Thanks for this great feedback! 😄

[satya2p]

@philip-gai Do you have an ETA ?

[philip-gai]

No I do not, however we look at the backlog each quarter and this is high on the list!

[pavlospt]

Is there an API for this? We would love to have one to integrate those metrics in application related dashboards 🙏🏻

[philip-gai]

There is not an API for this yet but it's on our roadmap!

[pavlospt]

Looking forward to it, as we recently had to built that from scratch and we most certainly might be missing some edge cases that this dashboard will probably dont miss 😄

[andrewjmeier]

Is the average for run time mean or median? It would be great to be able to remove some outliers or break them down by certain percentiles.

I think our data is skewed short by jobs that get cancelled early as well. Maybe those could be excluded?

[philip-gai]

The average for the run time is the mean. Your request makes sense - thank you for the feedback! 📓

[lure8225]

Any idea in which time-frame this makes it to the GHES (on premise) if at all?
We recently started migrating more things from a Jenkins environment and the lack of this and similar statstics/metrics seems to be one of the biggest pain points.

[lkfortuna]

Hi there 👋 We currently do not have plans to bring this feature to GHES. The biggest reason is that we do not have access to the metrics on GHES instances since they are on private servers. There would be a need for you to send the metrics to us first, and then we would resurface them back to you.

[lure8225]

Thanks for the information but very sad to hear this. My expectation/hope was the data collection and all the backend would be integrated in the GHES server.

[arnomijs]

Hi,

I have a couple of questions/remarks:

• Can the aggregations on top change based on the filters selected? This is not the case at the moment.

• Can custom properties be introduced as a filter option? This would be really helpful filtering out repo's.

• Can the reusable workflow be added as a filter option instead of to the calling workflow name?

• Will this be able to serve as a real time monitoring solution in the future? I see that now it's mostly to 21 minutes ago, 1 hour ago, ...
  Are there plans to decrease this interval to be (almost) real time?

Thanks in advance, great feature!

[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.

In addition some of these are stacked a few levels deep in the hierarchy (e.g. reuse-build may have reuse-action-1 as part of it) - so the API isn't much use either (as detailed here https://docs.github.com/en/actions/sharing-automations/reusing-workflows#monitoring-which-workflows-are-being-used)

[astendal]

I would LOVE to be able to measure performance of reusable actions and workflows. +1 to this.