> For the complete documentation index, see [llms.txt](https://docs.kosmoslabs.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kosmoslabs.ai/product-documentation/integration-limits.md).

# Integration Limits

System limits and rate constraints by integration

***

Kosmos applies sensible limits to ensure reliable performance across all connected systems. This page documents current limits by integration.

### Why Limits Exist

During the 90-day Historical Baseline and ongoing sync, Kosmos ingests data from multiple systems. Limits prevent:

* Exceeding provider API rate limits
* System overload with very large repositories or orgs
* Slow sync times that delay your results

Most customers never hit these limits. If you do, they're configurable—talk to your Kosmos team.

***

### GitHub

| Limit                  | Default      | Notes                               |
| ---------------------- | ------------ | ----------------------------------- |
| Repositories displayed | 50           | In configuration screen; adjustable |
| Max items per sync     | 10,000       | Across all repos                    |
| Items per repository   | 500          | Per sync cycle                      |
| Commits per repo       | 500          | Most recent                         |
| Pull requests per repo | 200          | Most recent                         |
| API rate limit         | \~5,000/hour | GitHub's standard limit             |

**What this means:** For most teams, Kosmos captures your full deployment history. Very large monorepos or orgs with 100+ active repos may need limit adjustments.

***

### Bitbucket

| Limit                  | Default | Notes                           |
| ---------------------- | ------- | ------------------------------- |
| Repositories displayed | 200+    | Paginated; all repos accessible |
| Commits per repo       | 500     | Most recent                     |
| Pull requests per repo | 200     | Most recent                     |

**What this means:** Kosmos paginates through all repositories in your workspace. Very large workspaces with 200+ repos are fully supported.

***

### Jira

| Limit                 | Default | Notes                   |
| --------------------- | ------- | ----------------------- |
| Max results per query | 5,000   | Jira API constraint     |
| Page size             | 100     | Per API request         |
| Max projects          | 100     | In configuration screen |

**What this means:** Covers the vast majority of Jira instances. If you have 5,000+ issues in a 90-day window, we'll capture the most recent.

***

### Salesforce

| Limit                | Default | Notes            |
| -------------------- | ------- | ---------------- |
| Max records per sync | 5,000   | Cases, incidents |
| Batch size           | 200     | Per API request  |

**What this means:** Sufficient for most Service Cloud implementations. High-volume support orgs (10K+ cases/quarter) may need adjustments.

***

### ServiceNow

| Limit                | Default | Notes                      |
| -------------------- | ------- | -------------------------- |
| Max records per sync | 5,000   | Incidents, change requests |
| Page size            | 100     | Per API request            |

**What this means:** Covers most ITSM implementations. High-volume environments may need adjustments.

***

### Zendesk

| Limit                | Default | Notes           |
| -------------------- | ------- | --------------- |
| Max tickets per sync | 5,000   | Support tickets |
| Page size            | 100     | Per API request |

**What this means:** Sufficient for most support organizations.

***

### Pylon

| Limit               | Default | Notes                        |
| ------------------- | ------- | ---------------------------- |
| Max issues per sync | 5,000   | Support issues and tasks     |
| Message enrichment  | Opt-in  | Configurable per integration |

**What this means:** Covers most Pylon implementations. Message enrichment can be enabled for deeper context.

***

### Linear

| Limit               | Default | Notes                                   |
| ------------------- | ------- | --------------------------------------- |
| Max issues per sync | 5,000   | Most recent, across all selected teams  |
| Page size           | 50      | Per GraphQL request                     |
| Comments per issue  | 20      | Most recent (when comment sync enabled) |

**What this means:** Covers the vast majority of Linear workspaces. Very high-volume teams with 5,000+ updated issues in a sync window may need limit adjustments.

***

### Azure DevOps

| Limit                   | Default | Notes                                     |
| ----------------------- | ------- | ----------------------------------------- |
| Max work items per sync | 5,000   | Most recent, across all selected projects |
| Batch size              | 200     | Per API request                           |
| Max projects displayed  | 100     | In configuration screen                   |
| Comments per issue      | 20      | Most recent (when comment sync enabled)   |

**What this means:** Covers most Azure DevOps organizations. Very large organizations or projects with high change velocity may need limit adjustments.

***

### OpenTelemetry (Preview)

| Limit               | Default       | Notes                     |
| ------------------- | ------------- | ------------------------- |
| Data retention      | 7 days        | Raw traces, logs, metrics |
| Correlation cadence | 15 minutes    | Batch processing interval |
| Request rate        | 1,000 req/min | Per customer              |
| Payload size        | 5 MB          | Per request               |

**What this means:** OTel data is processed in 15-minute batches for correlation. Raw data is retained for 7 days; correlation metadata is retained with your other signals.

***

### Adjusting Limits

All limits are configurable. If you're hitting a limit that affects your results, contact your Kosmos team. Common adjustments:

* Increasing repository count for large GitHub orgs
* Extending record limits for high-volume Salesforce orgs
* Adjusting sync frequency for real-time needs

***

### FAQ

**Q: Will I lose data if I hit a limit?** No. Kosmos captures the most recent data up to the limit. Older records outside the limit aren't deleted—they're just not synced.

**Q: How do I know if I'm hitting a limit?** Your Kosmos team monitors sync health and will proactively reach out if limits are affecting your results.

**Q: Can limits be increased?** Yes. Limits are configurable per customer. Higher limits may increase sync time but won't affect platform stability.

**Q: Do limits affect real-time monitoring?** No. Limits primarily apply to the initial Historical Baseline. Ongoing monitoring processes new data as it arrives.

**Q: How long does the Historical Baseline take?** Typically under 10 minutes for 90 days of data. Very large datasets may take longer; your Kosmos team will keep you informed.

**Q: What about rate limits from the providers (GitHub, Jira, Salesforce)?** Kosmos respects provider rate limits automatically. We batch requests and throttle as needed to avoid hitting provider limits.

***

**Questions?** Contact <support@kosmoslabs.ai> | [app.kosmoslabs.ai](https://app.kosmoslabs.ai/)

© 2026 Kosmos AI Labs, Inc.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.kosmoslabs.ai/product-documentation/integration-limits.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
