Skip to content

Increased Concurrency Limit for GitHub-Hosted Runners

GitHub-hosted runners now support up to 1000 concurrent jobs for our 4 – 64 vCPU runners, enhancing their capability to handle large-scale CI/CD workloads.

Our runners are designed to automatically scale to meet your needs. The concurrency limit feature allows users to specify the maximum number of jobs that can run simultaneously to execute Actions workflows. Previously capped at 250, we've made backend improvements to now support a maximum of 1000 concurrent jobs for runners within the 4-64 vCPU range for Windows and Linux operating systems.

Enterprise or organization administrators can set this concurrency limit under the Auto-scaling setting. GitHub-hosted runners with 4 or more vCPUs are available on both the GitHub Team and Enterprise plans.

If you have any feedback to help improve this experience, be sure to post it on our GitHub Community Discussion.

Auto-triage rules are a powerful tool to help you reduce false positives and alert fatigue substantially, while better managing your alerts at scale.

Starting today, you can now create your own custom rules to control how Dependabot auto-dismisses and reopens alerts – so you can focus on the alerts that matter, without worrying about the alerts that don’t.

What’s changing?

For any existing or future alerts that match a custom rule, Dependabot will perform the selected behavior accordingly. You can proactively filter out false positives, snooze alerts until patch release, and – as rules apply to both future and current alerts – manage existing alerts in bulk.

Frequently asked questions

Why is GitHub making this change?

At GitHub, we’ve been thinking deeply about how to responsibly address long-running issues around alert fatigue and false positives. Rather than over-indexing on one criterion like reachability or dependency scope, we believe that a responsibly-designed solution should be able to detect and reason on a rich set of complex, contextual alert metadata.

That’s why, moving forward, we’re releasing a series of ships powered by an underlying, all-new, flexible and powerful alert rules engine. Our first ship – Dependabot presets – leveraged our rules engine with GitHub-curated vulnerability patterns. Today’s ship exposes our rules engine so you can create your own rules, too.

Which criteria are supported?

Rules can be created across the following attributes:

Attribute Description
severity Alert severity, based on CVSS base score, across the following values: low, medium, high, and critical.
scope Scope of the dependency: development (devDependency) or runtime (production).
package-name Packages, listed by package name.
cwe CWEs, listed by CWE ID.
ecosystem Ecosystems, listed by ecosystem name.
manifest Manifest files, listed by manifest path.

What behaviors are supported?

Create or edit a custom rule

Today’s ship covers support for auto-dismissing alerts indefinitely as well as snoozing alerts until patch. Auto-dismissing ensures all activity is easily visible and can be caught by existing reporting systems and workflows, while also ensuring that alerts can be reintroduced if metadata across the alert changes.

How will this activity be reported?

Auto-dismissal activity is shown in webhooks, REST, GraphQL, and the audit log for Dependabot alerts. Alerts are dismissed without a notification or new pull request and appear as a special timeline event. As these alerts are closed, you’ll still be able to review any auto-dismissed alerts with the resolution:auto-dismissed filter.

Who can create and modify rules?

Auto-triage rules are free for open source repositories. Anyone who can enable Dependabot alerts for a public repository will be able to create custom rules for it. Customers of GitHub Advanced Security can create and manage custom rules across private repositories.

How do I reopen an automatically dismissed alert?

Like any manually dismissed alert, you can reopen an auto-dismissed alert from the alert list view or details page. This specific alert won’t be auto-dismissed again (by any other auto-dismiss rule).

What happens if alert metadata changes or advisory information is withdrawn?

Dependabot recognizes and immediately responds to any changes to metadata which void auto-dismissal logic. For example, if you change the dependency scope and the alert no longer meets the criteria to be auto-dismissed, the alert will automatically reopen.

How do I learn more?

How do I provide feedback?

Let us know what you think by providing feedback — we’re listening!

See more