We are having trouble with our current monitoring tool's API limits. What platforms offer more generous API access for custom automation?
Our current monitoring tool keeps hitting API rate limits when we try to run custom automation scripts. Which observability platforms are known for having higher or more flexible API limits?
Hitting API rate limits (HTTP 429) during custom automation usually happens because an observability tool's REST or GraphQL API is designed for interactive UI dashboards rather than heavy programmatic polling or bulk writes.[](https://docs.datadoghq.com/api/latest/rate-limits/)
We are looking to switch monitoring providers because our current one throttles our custom automation workflows. What are some options that offer more open API access?
Observability Platforms with Flexible or High API Limits
New Relic (NerdGraph API & Data APIs)
API Style: Uses a unified GraphQL API (NerdGraph ) alongside high-capacity telemetry ingestion pipelines.
Limits Profile: New Relic is exceptionally generous with query volume compared to traditional tools, allowing up to 3,000 queries per account per minute for NRQL queries. Their data ingestion rate limits scale heavily (e.g., up to 55 million records per account per minute for ingestion).
API Style: Open-source friendly, heavily reliant on standard remote-write and pull protocols rather than proprietary rate-restricted REST endpoints.
Limits Profile: Because Grafana Cloud builds on Prometheus, Mimir, and Loki, metric ingestion and querying rely on native data-pipeline throughput rather than strict per-endpoint request caps. While individual stack resource limits exist, they rarely block standard custom automation scripts the way rigid SaaS REST APIs do.
API Style: Comprehensive REST API, but notoriously strict out-of-the-box limits on specific endpoints (e.g., metric retrieval is capped at 100/hr, timeseries queries at 1,600/hr, and graph snapshots at 60/hr on standard tiers).
Limits Profile: While Datadog does enforce strict default caps, their enterprise tiers allow you to negotiate and explicitly request higher rate limits through your account team. Data point/metric submission via their intake API is also decoupled from standard retrieval rate limits.
Batch requests: Combine multiple metrics or entities into a single payload instead of making individual loops for each resource.
Cache responses: Store static or slowly changing metadata (like host IDs, service tags, or configuration objects) locally rather than re-querying the API on every script execution.
If your monitoring tool is frequently returning API rate-limit errors, I’d prioritize observability platforms that offer documented rate limits, ways to request higher quotas, and APIs designed for efficient automation—rather than simply choosing the vendor with the biggest advertised number.
Based on current vendor documentation, Datadog and Dynatrace are worth evaluating for flexible API access, while New Relic is particularly interesting if your scripts can consolidate queries through GraphQL. The best fit depends on whether you're querying metrics, pulling logs, checking alerts, or managing monitoring configuration.
Platforms worth evaluating
1. Datadog
(Best for negotiable limits)
Datadog explicitly allows customers to request increases to default API rate limits through support. It also documents rate-limit headers so scripts can track remaining quota and reset times. Its log-submission API is not rate-limited, and event submission supports 250,000 events per minute per organization. These are specific API behaviors, not a universal quota for every endpoint.
Best for: Teams that want a mature SaaS platform and a route to higher quotas without rebuilding their automation.
Official docs:
2. Dynatrace
(Best for variable workloads)
Dynatrace uses a request-throttling model based on each environment's processing capacity, queue, and request cost. This can accommodate many inexpensive requests without applying a simple fixed requests-per-minute ceiling to every operation. Expensive requests and overloaded environments can still return HTTP 429 errors.
Best for: Enterprise monitoring automation with mixed workloads and many API operations.
Official docs:
3. New Relic
(Best for query-heavy scripts)
New Relic's NerdGraph GraphQL API allows scripts to retrieve specific data through a unified interface. Its documented limit is 25 concurrent requests per user, rather than a general requests-per-second limit for NerdGraph. Separately, NRQL queries have their own limits, including 3,000 API queries per account per minute and a 120-per-minute limit for repetitive queries.
Best for: Automation that can consolidate multiple data lookups into fewer queries. Less attractive if your main issue is excessive concurrent requests.
Official docs:
4. Grafana Cloud
Grafana Cloud offers APIs for managing cloud resources and separate HTTP APIs for working with dashboards, alerts, and data sources. Limits vary by API; for example, its access-policy API has a documented limit of 600 requests per hour. That specific limit should not be generalized to every Grafana API.
Best for: Teams that want flexible observability architecture and the option to self-host parts of their stack. Verify the specific Cloud API limits before choosing it to solve throttling.
Official docs:
5. Elastic Observability
Elastic exposes APIs for alerting, SLOs, APM, uptime monitoring, and other observability functions. Self-managed deployments offer more control over infrastructure and capacity, which can help when limits stem from a hosted service's fixed quotas. However, self-hosting does not eliminate resource constraints or API-specific limits.
Best for: Engineering teams willing to manage their own infrastructure in exchange for greater operational control.
Official docs:
How I'd shortlist them
Your main requirement
Start with
Higher quotas that you can request
Datadog
Many inexpensive API calls with variable workload costs
Dynatrace
Efficient querying across observability data
New Relic
Open ecosystem and deployment flexibility
Grafana / Elastic
Maximum control over infrastructure capacity
Self-managed Elastic or Grafana stack
These are recommendations based on documented API behavior and deployment options, not a verified ranking of which vendor permits the most calls overall.
Before migrating, check what is actually being throttled
A 429 response can mean very different things depending on the API:
Fixed rate limit: You exceed a requests-per-minute quota.
Concurrency limit: Too many requests are in flight at once.
Query limit: Your queries are too frequent or computationally expensive.
Ingestion limit: You're sending too much telemetry.
Account or plan limit: Your subscription imposes a quota that may be adjustable.
Adding retries alone often makes the problem worse if requests continue at full speed. Use exponential backoff with jitter, respect Retry-After or vendor-specific reset headers, limit concurrent requests, and batch or cache repetitive lookups where possible.
One question to narrow this down
Which monitoring tool are you using today, and what do your scripts mainly do?
Current platform
Datadog
New Relic
Grafana
Dynatrace
Elastic
Other or custom-built
Automation workload
Query metrics, logs, or traces
Fetch alert or monitor status
Create or update monitors and configuration
Send telemetry or events
Run many API calls concurrently
Preferred deployment
Managed SaaS
Self-hosted
Either
[Compare the best-fit alternatives]
With those details, I can narrow this to the most practical alternatives rather than recommend a platform that may have the same bottleneck.
If your current monitoring provider is throttling custom automation workflows, I’d focus on platforms that offer well-documented APIs, configurable rate limits, and the option to run monitoring infrastructure yourself. The best fit depends on whether you monitor application performance, servers and infrastructure, uptime, logs, or a mix of these.
One important distinction: an open API doesn't necessarily mean unlimited API calls. Some hosted vendors have endpoint-specific quotas, while self-hosted platforms give you more control over the infrastructure and request volume.
Monitoring providers worth evaluating
1. Grafana Cloud / Grafana OSS
(Best overall flexibility)
A strong starting point if you want to automate dashboards, alerts, data sources, and metrics workflows. Grafana provides HTTP APIs, and its open-source ecosystem includes Prometheus, Loki, and Tempo. You can also self-host components for greater control over your infrastructure.
Trade-off: Grafana Cloud still imposes API limits on some endpoints; its documented access-policy API limit is 600 requests per hour.
An open-source metrics monitoring system with a documented HTTP API and a machine-readable OpenAPI specification. Because you operate the server, you can tune capacity and query workloads to suit your automation needs rather than depend on a hosted vendor's API quota.
Trade-off: You manage deployment, scaling, storage, and availability. Prometheus is primarily a metrics system, not a complete all-in-one monitoring service.
Link:
3. Zabbix
(Best for infrastructure monitoring)
A self-hostable platform for servers, networks, services, and infrastructure. Its API supports retrieving monitoring history and events, managing configuration, and integrating alerting into external workflows.
Trade-off: It requires more operational ownership and has a different workflow and data model from application-focused observability tools.
Link:
4. Datadog
(Best managed enterprise option)
Worth considering if you want a mature hosted platform with broad integrations and extensive APIs. Datadog documents endpoint-specific rate limits and provides headers that let automation track remaining quota and reset times. Some limits can be increased by contacting support.
Trade-off: It is not an unlimited-API alternative. Verify the exact endpoints your workflows call and get any required quota increases confirmed before migrating.
Link:
5. New Relic
A managed alternative for application performance monitoring, infrastructure, logs, and traces. Its APIs and GraphQL-based NerdGraph interface support programmatic access and configuration. However, New Relic also enforces request-rate and query limits, so assess your specific automation patterns before switching.
Trade-off: A broad API surface doesn't guarantee higher request quotas for your particular use case.
Link:
How I'd shortlist them
Your priority
Start with
Maximum control over API usage
Prometheus, self-hosted
Flexible observability with dashboards and alert automation
Grafana
Server and network monitoring
Zabbix
Managed, enterprise-scale observability
Datadog
Managed application performance monitoring
What to verify before switching
Don't compare providers on the phrase “open API” alone. Test the workflows that are currently being throttled and ask each vendor:
Rate limits: What are the per-endpoint quotas, burst limits, and daily caps?
Quota increases: Can limits be raised contractually, or are they fixed by plan?
Automation capabilities: Can you create, update, acknowledge, and resolve alerts programmatically?
Bulk operations: Are batch requests, pagination, webhooks, or event ingestion available to reduce API calls?
Failure behavior: Are 429 Too Many Requests responses accompanied by reset information, and can your workflows safely retry?
Data access: Can you query historical metrics, logs, and events without relying on expensive or heavily restricted endpoints?
One particularly important distinction: if your automation repeatedly reads monitoring data, the query API's limits matter most. If it creates alerts, sends events, or updates configuration, you need to inspect those specific write endpoints instead.
One question to narrow this down
What kind of monitoring are you switching from?
1. Monitoring category
Infrastructure, servers, and networks
Application performance (APM), traces, and errors
Uptime checks and synthetic monitoring
Logs and security monitoring
A combination of these
2. Deployment preference
Fully managed SaaS
Self-hosted
Either is fine
3. Where do you hit the limit?
Reading or querying monitoring data
Creating alerts, updating configuration, or sending events
Sending metrics, logs, or traces into the platform
Multiple workflows or not sure
[Find the best-fit alternatives]
With those details, I can narrow this to the most relevant two or three providers and compare their documented API limits against your automation requirements.
