• The runner always calls the GitHub API to resolve actions first, even if they’re cached
• ACTIONS_RUNNER_ACTION_ARCHIVE_CACHE only avoids downloading, not resolving
• API rate limits apply to the resolution step, which is why you still see failures
• Using commit SHA instead of tags does not prevent API calls
• Anonymous or weakly authenticated runners hit limits much faster

To reduce rate limits:

• Use a properly configured token (PAT or GitHub App)
• Prefer a GitHub App with Actions Runner Controller
• Reduce number of job startups (fewer, longer-lived runners)
• Avoid excessive matrix or highly parallel workflows
• Fork/vendor frequently used actions to stabilize references
• Consider GitHub Enterprise Server for large-scale setups

So basically cache helps with downloads, not API rate limits

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬

🛠️ Resolving API Rate Limits on Self-Hosted Runners

The ACTIONS_RUNNER_ACTION_ARCHIVE_CACHE environment variable only optimizes the download phase; it does not bypass the mandatory API call required to resolve action metadata. To resolve the rate limiting, follow these steps:

1. Authenticate the Runner

• Use a GitHub App: This is the most effective solution for ARC/Kubernetes runners. It provides significantly higher rate limits (5,000 requests per hour) compared to unauthenticated requests.
• Configure a PAT: If not using a GitHub App, ensure your runner is configured to use a Personal Access Token (PAT) with appropriate repo scope to authenticate API calls.

2. Implement Runner Caching Strategy

• Actions Runner Controller (ARC): Ensure you are running the latest version of ARC, as it is designed to manage authentication and scaling for Kubernetes runners more efficiently than manual installations.

3. Optimize Workflow Configuration

• Consolidate Jobs: If possible, reduce the number of concurrent jobs triggering simultaneous API resolution calls.
• Action Pinning: While pinning to SHA does not stop the API check, it is still a best practice for security; ensure you are not using "floating" tags (e.g., @v1) that force frequent re-resolution.

4. Vendor Critical Actions

• Self-Host Actions: For mission-critical workflows, download the necessary actions and host them within your own organization or repository. This can stabilize resolution behavior, though the runner will still perform minimal validation against the source.

Are you currently authenticating your runner using a GitHub App or a Personal Access Token?