---
title: Managed inputs rate limiting
description: Rate limiting for Elastic Cloud managed inputs.
url: https://www.elastic.co/elastic/docs-builder/docs/3764/reference/opentelemetry/managed-inputs/rate-limiting
products:
  - Elastic Cloud Hosted
  - Elastic Cloud Serverless
  - Elastic Observability
  - Elastic Security
applies_to:
  - Elastic Cloud Serverless: Generally available
  - Elastic Cloud Hosted: Generally available
---

# Managed inputs rate limiting
Rate limiting occurs when a managed input receives data faster than it can process and index into Elasticsearch. The endpoint responds with HTTP `429` errors until the data volume is reduced.

## How rate limiting works

Rate limiting behavior differs by deployment type:
- **Elastic Cloud Hosted**: Rate limits depend on your Elasticsearch cluster capacity. If your cluster can't keep up with incoming data, the endpoint starts rejecting requests with `429` errors.
- **Elastic Cloud Serverless**: Elastic manages scaling automatically. Rate limiting is rare and typically indicates a temporary event to protect our system.


## Identifying rate limiting

When rate limiting occurs, the managed input responds with an HTTP `429` Too Many Requests status code.
For the [Managed OTLP Endpoint](https://www.elastic.co/elastic/docs-builder/docs/3764/reference/opentelemetry/managed-inputs/managed-otlp-endpoint), a log message similar to this can appear in the OpenTelemetry Collector's output:
```
"error": "rpc error: code = ResourceExhausted desc = request exceeded available capacity"
```

For OTLP troubleshooting steps, refer to [Error: too many requests](/elastic/docs-builder/docs/3764/reference/opentelemetry/managed-inputs/troubleshooting#error-too-many-requests).
Elasticsearch output shippers such as Beats, Elastic Agent, and Logstash typically retry `429` responses automatically with backoff. Configure your shipper to queue data so transient rejections don't lose data.

## Resolving rate limiting


### Elastic Cloud Hosted deployments

For Elastic Cloud Hosted deployments, `429` errors typically indicate that your Elasticsearch cluster is undersized for the current data volume. If [AutoOps](/elastic/docs-builder/docs/3764/reference/opentelemetry/managed-inputs/troubleshooting#use-autoops-to-diagnose-issues) is available in your region, use it to check CPU utilization, index queue depth, and node load to confirm whether your cluster is under-resourced. If AutoOps is not available in your region, [contact Elastic Support](https://docs-v3-preview.elastic.dev/elastic/docs-builder/docs/3764/troubleshoot/ingest/opentelemetry/contact-support).
If metrics confirm the cluster needs more capacity, scale your deployment:
- [Scaling considerations](https://docs-v3-preview.elastic.dev/elastic/docs-builder/docs/3764/deploy-manage/production-guidance/scaling-considerations)
- [Resize deployment](https://docs-v3-preview.elastic.dev/elastic/docs-builder/docs/3764/deploy-manage/deploy/cloud-enterprise/resize-deployment)
- [Autoscaling in ECE and ECH](https://docs-v3-preview.elastic.dev/elastic/docs-builder/docs/3764/deploy-manage/autoscaling/autoscaling-in-ece-and-ech)

Once your Elasticsearch capacity is scaled up or is able to accept the incoming data volume, requests to managed inputs will be accepted again.

### Elastic Cloud Serverless deployments

For Elastic Cloud Serverless projects, Elastic manages scaling automatically. If you experience persistent `429` errors, [contact Elastic Support](https://docs-v3-preview.elastic.dev/elastic/docs-builder/docs/3764/troubleshoot/ingest/opentelemetry/contact-support).