New rate limit is coming for the audit log API endpoints

GitHub provides Enterprise customers with the ability to programmatically retrieve enterprise and organization audit log events in near real-time using the audit log API. A high-quality audit log is an essential tool used by enterprises to ensure compliance, maintain security, investigate issues, and promote accountability. To support these objectives, the audit log API needs to be highly reliable, consistently available, and extremely scalable.

Recognizing the audit log API's importance as a data source to enterprises, each audit log API endpoint will impose a rate limit of 15 queries per minute per enterprise or org starting August 1st, 2023. Based on a thorough analysis of event generation data, we are confident that the new rate limit will continue to support customers in accessing near real-time data via the audit log API. Additionally, query cost is a crucial consideration, and in the future, the audit log may impose further rate limiting for high-cost queries that place significant strain on our data stores.

What can you do to prepare for these changes? First, programs or integrations querying the audit log API should be adjusted to query at a maximum frequency of 15 queries per minute. Additionally, applications querying the audit log API should be updated to be capable of honoring HTTP 429 responses, enabling them to dynamically adjust to the back-pressure exerted by our systems. Alternatively, Enterprises seeking access to near real-time data should consider streaming your enterprise audit log.

Dependabot version updates helps you keep your dependencies up-to-date by opening pull requests when dependencies can be upgraded. With today's release, you can now group version updates by dependency name.

Until today, Dependabot would always open individual pull requests for every dependency update in accordance with your configuration in dependabot.yml. Not only can this result in a large number of Dependabot pull requests, but there are some dependencies which must be updated in tandem with each other or the update will fail. In these cases, the individual Dependabot pull requests would always fail until you manually intervened to do the update.

Now, in your dependabot.yml configuration file, you can set custom grouping rules for Dependabot based on pattern matching on package name. Here is an example of how these rules can be set up:

version: 2
  updates:
  - package-ecosystem: "bundler"
    directory: "/"
    schedule:
      interval: weekly
    # New!
    groups:
      # This is the name of your group, it will be used in PR titles and branch names
      dev-dependencies:
        # A pattern can be...
        patterns:
          - "rubocop" # a single dependency name
          - "aws*"  # or a wildcard string that matches multiple dependencies
          # If you'd simply like to group as many dependencies together as possible, 
          # you can use the wildcard * - but keep in mind this may open a very large PR!
        # Additionally, you can specify any dependencies to be excluded from the group
        exclude-patterns:
          - "aws-sdk"

This configuration applies to regularly scheduled Dependabot version updates only. Security updates for Dependabot will continue to open as individual pull requests, even if they match a configured grouping rule.

This feature is in beta, so you may encounter instability and the feature-set is currently limited. You may file any bugs encountered in the dependabot-core repo.

To learn more about grouping rules for Dependabot version updates, please refer to our documentation.

See more