Kubescape · Rate Limits

Kubescape Rate Limits

Neither the open-source Kubescape tool nor the hosted ARMO Platform Customer API publishes fixed numeric request-rate limits. For the open-source CLI and in-cluster Operator, scan throughput is bounded only by your own cluster and host resources. For the hosted ARMO Platform Customer API (https://api.armosec.io/api/v1), the effective ceiling is the plan's worker- node / data-retention allowance rather than a documented per-minute request cap; expect standard HTTP 429 throttling and Retry-After handling on the managed service.

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

It captures 4 rate-limit definitions, measuring requests, nodes, and scans.

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

Tagged areas include Kubernetes Security, Cloud Native Security, Container Security, Rate Limiting, and Quotas.

4 Limits Throttle: 429
Kubernetes SecurityCloud Native SecurityContainer SecurityRate LimitingQuotas

Limits

Customer API Requests account
requests
not published
No fixed numeric request-rate limit is documented for the ARMO Platform Customer API.
Worker Node Allowance account
nodes
per plan
ARMO Platform meters the number of protected worker nodes per plan tier rather than API calls.
Self-Hosted Scan Throughput deployment
scans
hardware-bound
Open-source CLI/Operator scanning is constrained by your own cluster and host resources, not by a vendor limit.
In-Cluster Component API cluster
requests
cluster-bound
OpenAPI/Swagger-documented Operator component APIs run inside your cluster; throughput is bounded by your resources.

Policies

Backoff Strategy
Clients of the ARMO Platform Customer API should implement exponential backoff with jitter and honor Retry-After on 429 responses.
Scheduled Scanning
Operator and registry scans run on configurable cron schedules; tune frequency to control load rather than relying on a request cap.

Sources