Clarification on Opsgenie API Limits and Pricing Model

Guneycan Sanli

I am evaluating a migration from PagerDuty to Opsgenie, and I need clarification on Opsgenie's API quotas and pricing model. PagerDuty enforces an annual API request limit (e.g., 8 million requests per year limit and then cost per every request), and I want to understand whether Opsgenie has similar limits in place.

I could not find any detailed documentation explaining API rate limits or usage caps for Opsgenie. Could someone from the community or Atlassian confirm:

1 -  Does Opsgenie impose API request limits (per day, month, or year)?

2- If so, what are the limits, and how are they calculated?

3 - Are higher limits available under specific pricing tiers or enterprise plans?

Any guidance or documentation references would be greatly appreciated.

Alexander Nilsson

Hello Guneycan,

I will be happy to give you more insights about this topic. 

1 – Does Opsgenie impose API request limits?
Yes. Opsgenie applies two types of limits:

- A runtime rate limit that throttles requests when too many calls are made in a short period (typically returning HTTP 429 “too many requests” when the threshold is exceeded).
- A commercial API usage quota, where your monthly allowance is tied to your subscription plan and number of users.

So there is both a technical protection mechanism and a licensing‑level quota, rather than an unbounded API.

 

2 – What are the limits and how are they calculated?

- On lower‑tier plans, you get a monthly API pool per account that scales with the number of licensed users (for example, formulas like “number of users × N API calls per month”). Once you hit that quota, further usage may be restricted or require a plan change.
- On higher‑tier / enterprise‑class plans, API usage is effectively treated as unlimited from a commercial perspective, meaning you are not expected to run into a numeric monthly or annual cap in normal usage; instead, you are primarily governed by the technical rate limiting.
- Independently of the commercial quota, Opsgenie enforces a short‑window per‑minute limit. If you exceed it, you’ll receive HTTP 429 responses and should implement backoff and retry logic in your integrations.

This is different from PagerDuty’s explicit “X million requests per year, then per‑call charges” model: Opsgenie’s limits are framed around monthly usage and plan tier, not a fixed annual figure.

 

3 – Are higher limits available under specific tiers or enterprise plans?

Yes. Moving from entry‑level plans to Standard / Enterprise‑class offerings typically increases or effectively removes the strict commercial API cap, so that only the technical throttling applies in day‑to‑day operations. For high‑volume or automation‑heavy scenarios (e.g. bulk syncs, Terraform, intensive alert fan‑out), Atlassian can review your projected load and, in some cases, tune limits for a given tenant as part of an enterprise agreement.

 

4 – Important: Opsgenie end‑of‑life (EOL)

Opsgenie is in an end‑of‑life phase:

- Opsgenie is no longer being sold to new customers.
- Existing customers are on a defined end‑of‑support and shutdown timeline over the next few years.

In other words, Opsgenie is a sunset product, and Atlassian’s strategy is to move its capabilities into other products rather than evolve Opsgenie as a standalone offering. Because of this, starting a new migration from PagerDuty to Opsgenie today means building on a product that will be phased out.

 

5 – Jira Service Management and Compass as recommended alternatives

Atlassian is effectively replacing Opsgenie’s capabilities with a combination of:

Jira Service Management (JSM)

- Incident management (major incident workflows, incident timelines, communication).
- Alert ingestion and correlation.
- On‑call and escalation policies (carrying over the Opsgenie‑style scheduling and routing into JSM).
- Integration with tickets, change management, and service management processes.

Compass
- Service catalog / service directory.
- Ownership and on‑call information (who owns which service, which team is on call).
- Context around services (dependencies, runbooks, links to repos, dashboards, etc.).

Together, JSM + Compass cover the functional surface that Opsgenie used to provide as a dedicated product: alert → on‑call routing → escalation → incident management in JSM, and service ownership / teams / operational context in Compass. If you are planning a fresh migration off PagerDuty, it is strongly recommended to evaluate Jira Service Management and Compass as the target rather than moving to Opsgenie, given its EOL status.

 

Greetings, 

Alex