AppDynamics · Rate Limits

Appdynamics Rate Limits

AppDynamics does not publish hard per-second rate-limit numbers for its Controller REST API or Metric & Snapshot API. Throughput is governed by the Controller's overall capacity (sized by edition and CPU/memory) and by per-account fairness throttling on SaaS Controllers. The Cisco AppDynamics Cloud Native (formerly AppDynamics Cloud) APIs follow Cisco's standard observability platform throttling. Heavy automation against the Controller REST API should batch requests, prefer the Metric & Snapshot API for time-series, and respect 429/503 responses with backoff.

Appdynamics Rate Limits is the machine-readable rate-limit profile for AppDynamics on the APIs.io network, conforming to the API Commons Rate Limits specification.

It captures 3 rate-limit definitions, measuring varies.

The profile also includes 3 backoff/retry policies defined and response codes documented for throttled and serviceUnavailable.

Tagged areas include Rate Limiting, APM, and Observability.

3 Limits Throttle: 429
Rate LimitingAPMObservability

Limits

Controller REST API account/controller
varies
see Controller capacity sizing
Sized by Controller edition and infrastructure; SaaS Controllers apply per-account fairness throttling.
Metric and Snapshot API account/controller
varies
see Controller capacity sizing
Heavy time-series queries can be throttled to protect shared Controller capacity.
Events Service / Analytics Events API account/region
varies
see service-specific quotas
Event ingestion sized by Events Service capacity in the customer's region.

Policies

Backoff Strategy
Implement exponential backoff with jitter; honor 429 / 503 responses with retries spaced across multiple seconds.
Batch and Aggregate
Use Metric & Snapshot API for time-series rather than per-call REST polls; batch event submissions.
Capacity Sizing
Throughput depends on Controller sizing (vCPU and edition); engage AppDynamics support to right-size if API automation pressures the Controller.

Sources