Add native performance metrics for GitHub Actions (e.g., average job duration, percentiles, trends)

[camilamaia]

🏷️ Discussion Type

Product Feedback

💬 Feature/Topic Area

Metrics & Insights

Discussion Details

Hello,

I would like to suggest improvements to the observability and performance insights available for workflows and jobs. Currently, while individual job durations are visible in each workflow run, there is no built-in way to access aggregated performance metrics such as:

• Average job duration (avg job time)
• Median and percentiles (p50, p95)
• Trends over time (e.g., identifying performance regressions or improvements)
• Aggregation by workflow, job, or branch

The existing "Actions Usage Metrics" section provides useful insights into billing and total usage, but it is primarily focused on consumption (e.g., total minutes used) rather than performance. It does not provide the level of detail needed to understand CI efficiency or identify bottlenecks.

Use case:
As a maintainer, I want to understand how long my workflows and jobs take on average and how this evolves over time, so I can optimize CI performance and improve developer experience.

Suggested solution:

• Provide aggregated performance metrics directly in the GitHub Actions UI
• Allow filtering by workflow, job, branch, and time range
• Include percentiles (p50, p95) and trend visualizations
• Expose these metrics via API for external integrations

Today, achieving this requires building custom tooling on top of the API or relying on third-party integrations, which adds unnecessary complexity.

Having these insights available natively would significantly improve CI observability and help maintainers and teams better manage performance.

Thank you for considering this feature!

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[syedsafeer]

This is a much-needed suggestion. Currently, the "Actions Usage Metrics" are almost entirely focused on billing and consumption, which doesn't help at all when trying to identify bottlenecks or optimize CI performance.

Until GitHub adds this natively, the only real workarounds are:

1. GitHub API: Pulling run data via /repos/{owner}/{repo}/actions/runs and calculating your own medians/percentiles using a script.
2. Third-party Tooling: Using open-source exporters (like the Prometheus GitHub exporter) to pipe data into Grafana for proper trend visualization.
   Having these metrics natively in the UI would save teams a lot of time building custom observability tools. I really hope the GitHub team considers this!

(If this clarifies the current situation and workarounds, please Mark as Answer.)

[Anjalipal12]

GitHub Actions is missing something pretty fundamental: real performance observability.

Right now we get logs and basic insights, but no real way to answer:

Why is this pipeline getting slower over time?
Is the bottleneck my code, the runner, or queueing?
Am I wasting CI money without realizing it?

What’s needed is a native metrics layer inside Actions, not just external dashboards.

Imagine if Actions exposed:

Step-level timing (not just total job duration)
p95/p99 workflow execution trends
Queue time vs execution time separation
Cost per workflow run
Flaky step detection across repos
Regression alerts when CI slows down after commits

Basically: CI should behave like a production system with observability baked in, not something you debug manually through logs.

Without this, teams are flying blind at scale.

[Payal-goell]

I am starting this discussion to propose better performance observability in GitHub Actions. While current metrics show workflow usage and billing, they lack aggregated performance insights such as average job duration, percentiles, and trends over time. Adding these metrics would help maintainers identify bottlenecks, optimize CI workflows, and improve overall developer productivity.

[Ankit-Sharma1011]

I often have to compare workflow durations manually. Built-in historical metrics and trend analysis would significantly improve debugging and CI optimization. Hope to see this implemented!

[sanathkmr14]

Hi everyone,I strongly support this request. Natively tracking performance health is the logical next step for GitHub Actions observability.Right now, the platform is great at telling us what we are spending (via usage metrics), but it falls short in telling us how efficient our pipelines actually are. Relying on custom API scrapers or heavy third-party monitoring tools just to get basic percentile data ($p50$/$p95$) adds a layer of operational overhead that shouldn't be necessary for standard CI/CD maintenance.Having native trend visualizations and filtering would specifically help teams:Catch Performance Regressions Early: Instantly see if a recent dependency update or architectural change caused a slow creep in test execution times.Optimize Developer Experience: Pinpoint the exact bottleneck jobs within a complex matrix or workflow to target optimization efforts where they matter most.Isolate Branch Noise: Easily filter out experimental branches to see the true performance baseline of main or production.