> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Rate Limits Token Lifecycles

> Describes GitHub token types, rate limits, and lifecycles, recommending GitHub Apps with per installation rate limits and short lived tokens for secure high volume automation

When operating at enterprise scale, security isn't the only concern — request throttling (rate limiting) is equally important. Understanding how GitHub applies rate limits to different token types and how token lifecycles work is critical for designing reliable, secure automation and CI/CD pipelines.

![An infographic showing multiple input lines merging into a central "Security" shield icon on a horizontal timeline. To the right it labels the "GitHub API" with the note "Every request counted" and the header reads "Security Is Not the Only Worry."](https://mintcdn.com/kodekloud-c4ac6d9a/TlnHw4JjIHBx3Cta/images/GitHub-Administration-Certification/Security-and-Compliance/Rate-Limits-Token-Lifecycles/security-shield-timeline-github-api.jpg?fit=max\&auto=format\&n=TlnHw4JjIHBx3Cta\&q=85\&s=2ab5af988beddff3d4ca33fd73d2f93f)

Key distinction: tokens that represent an individual user are rate-limited differently than tokens that represent an application identity. This difference often determines whether high-volume automation succeeds or fails.

![A simple diagram titled "Two Pipes to the Same API" showing one API on the left branching into two connections: a red "User tokens" line tied to a person icon and a blue "GitHub Apps" line representing an app identity with a robot icon. Each branch is labeled to show user tokens are tied to a person while GitHub Apps have their own identity.](https://mintcdn.com/kodekloud-c4ac6d9a/TlnHw4JjIHBx3Cta/images/GitHub-Administration-Certification/Security-and-Compliance/Rate-Limits-Token-Lifecycles/pipes-api-user-tokens-gh-apps.jpg?fit=max\&auto=format\&n=TlnHw4JjIHBx3Cta\&q=85\&s=5f3a2c08b7f1ca4633eed232a555f2d2)

Token types and rate limits

| Token Type | Identity Bound To | Rate Limit | Typical Token Lifetime | Recommended Use |
| -: | - | -: | - | - |
| User token (classic PAT, fine-grained PAT, OAuth app token) | An individual user | `5,000` requests per hour (shared across everything the user does) | Can be long-lived (configurable) | Personal use, manual CLI/browser access, low-volume automation |
| GitHub App (installation access token) | The app installation (per repository/org) | `15,000` requests per hour per installation | `1 hour` (installation token), JWT for auth short-lived (up to \~10 minutes) | High-volume automation, CI/CD, bots, integrations |

Read more: [GitHub Apps documentation](https://docs.github.com/en/apps) and [API rate limits](https://docs.github.com/en/rest/overview/resources-in-the-rest-api#rate-limiting).

Any token tied to a person — for example a classic personal access token, a fine-grained personal access token, or an OAuth app token — is subject to the user rate limit of 5,000 API requests per hour. That single 5,000/hour bucket is shared across everything the user does: browser sessions, CLI tools, scripts, and CI jobs that reuse the user's identity.

![Slide titled "Any Token Tied to a Person" showing a human user icon and two boxed token options labeled "Classic PAT" and "Fine-grained PAT." Each box includes a key icon and an obfuscated token preview (e.g., ghp\_... and github\_pat\_...).](https://mintcdn.com/kodekloud-c4ac6d9a/TlnHw4JjIHBx3Cta/images/GitHub-Administration-Certification/Security-and-Compliance/Rate-Limits-Token-Lifecycles/token-tied-to-person-pat.jpg?fit=max\&auto=format\&n=TlnHw4JjIHBx3Cta\&q=85\&s=5e49c1dcec7620422f44bad0606063c3)

By contrast, a GitHub App is an identity of its own. Each installation of a GitHub App receives a larger, separate rate limit: 15,000 requests per hour per installation. That isolation (and the higher quota) makes GitHub Apps much better suited for automation that generates many API requests — for example, CI jobs that repeatedly check statuses, post comments, or merge pull requests.

![An infographic titled "A GitHub App Gets Its Own" showing two stylized cups/bars: a small orange cup on the left labeled "5,000" and a much taller blue cup on the right with a small robot icon above it.](https://mintcdn.com/kodekloud-c4ac6d9a/TlnHw4JjIHBx3Cta/images/GitHub-Administration-Certification/Security-and-Compliance/Rate-Limits-Token-Lifecycles/github-app-5000-vs-robot.jpg?fit=max\&auto=format\&n=TlnHw4JjIHBx3Cta\&q=85\&s=fe31e875561fc411021bd761aee67d23)

Example: common CI job API patterns that add up quickly

```text theme={null}
api-calls.log

POST /repos/{owner}/{repo}/statuses/{sha}
POST /repos/{owner}/{repo}/issues/{n}/comments
PUT /repos/{owner}/{repo}/pulls/{n}/merge
# Merge code
```

If those calls run across many repos or commits, a user-scoped token can hit the 5,000/hour bucket fast; a GitHub App installation is far less likely to run into the 15,000/hour limit for the same workload.

Token lifecycle: why GitHub Apps are more secure

A GitHub App does not authenticate with a long-lived secret alone. Instead:

* The app holds a private key.
* The app generates a short-lived JSON Web Token (JWT) signed with that private key. GitHub currently limits JWT validity to a short window (typically up to 10 minutes).
* The app exchanges the JWT for an installation access token.
* The installation access token is valid for exactly one hour.

This short, one-hour lifetime is a deliberate security feature: if an installation access token is leaked or intercepted, it becomes useless quickly.

![A slide titled "A Stolen Token Dies on Its Own." On the right is a blue circular timer that reads "60 minutes left" with the label "Installation token."](https://mintcdn.com/kodekloud-c4ac6d9a/TlnHw4JjIHBx3Cta/images/GitHub-Administration-Certification/Security-and-Compliance/Rate-Limits-Token-Lifecycles/installation-token-60-minutes-timer.jpg?fit=max\&auto=format\&n=TlnHw4JjIHBx3Cta\&q=85\&s=b5886b5254739aca1f0e93a47da37b36)

Compare that to classic personal access tokens, which can be configured with long expiry or no expiry at all. Long-lived tokens broaden the attack window if compromised.

Best practices and recommendations

* Prefer GitHub Apps for automation that makes many API requests (CI, bots, status checks).
* Use installation access tokens instead of user tokens for CI/CD to isolate rate limits and improve throughput.
* Rotate keys and use the short JWT + installation token flow for apps; avoid embedding long-lived tokens in CI configuration.
* Monitor rate-limit headers in API responses and implement exponential backoff or request batching when close to limits.
* Centralize automation under dedicated service accounts or app installations rather than reusing personal credentials.

Use GitHub Apps for high-volume automation and short-lived credentials. Their per-installation rate limits and one-hour installation tokens provide both higher throughput and stronger security for CI/CD and other automated workflows.

> [card] [Watch Video](https://learn.kodekloud.com/user/courses/github-administration-certification/module/d477d0b2-5ca0-43b2-aed7-7d82887400f7/lesson/bd4d8b5a-026d-40b1-a0af-bcf7eb307e59)

> [card] [Practice Lab](https://learn.kodekloud.com/user/courses/github-administration-certification/module/d477d0b2-5ca0-43b2-aed7-7d82887400f7/lesson/c887863f-0dfa-4d45-9275-5c1e3f12e0d6)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.