Problem

After migrating from Opsgenie to Jira Service Management Operations, customers lose access to the API Usage Analytics, API Usage Analytics by Time, and API Rate Limit reports that were previously available in Opsgenie (these are officially listed as deprecated). There is currently no equivalent customer-facing dashboard or tooling in JSM to:

• View the quota allocated to a tenant for each API rate-limit domain
• See the exhaustive list of API rate-limit domains
• Monitor current API quota usage across the tenant
• Review historical API usage statistics and KPIs broken down by API key, personal user token, or OAuth 2.0 token
• Identify which user or integration token is consuming the most API calls

The only mechanism available today is inspecting HTTP response headers (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, Retry-After) on individual API responses, which is reactive and provides no aggregated or historical view. Since JSM Ops REST API rate limits are applied at the tenant + rate-limit domain level, a single user or token over-consuming API calls can exhaust the rate limit budget for every user and integration across the entire site, yet administrators have no way to proactively detect or diagnose this.

Additionally, many customers who migrated from Opsgenie continue to rely heavily on Opsgenie API keys for the
The Jira Service Management ops REST API, which uses GenieKey authentication rather than standard API tokens or OAuth 2.0. This API surface has its own rate limiting behavior and is equally lacking in monitoring visibility. The deprecated Opsgenie reports previously covered this API surface as well.

Suggested Solution

Provide a customer-facing API usage monitoring dashboard within JSM Operations (or Atlassian Admin) that enables site administrators to:

1. View configured rate limit thresholds per rate-limit domain (e.g., alert, schedule, etc.)
2. Monitor real-time and historical API consumption per tenant, broken down by API key / user token / OAuth 2.0 token
3. See usage trends and KPIs over configurable time periods
4. Identify which token or user is consuming the most API calls per domain
5. Set up alerts/notifications when usage approaches rate limit thresholds
6. Cover both API surfaces, the JSM Ops REST API v2 (API token / OAuth 2.0) and the Integration Events API v1 (Opsgenie API key / GenieKey authentication), so administrators have unified visibility across all API consumption regardless of authentication method

This would restore feature parity with the Opsgenie analytics reports that customers relied on prior to migration.

Why This Is Important

Enterprise customers with large user bases and many integrations across multiple teams rely heavily on the JSM Ops REST API. Without visibility into API consumption, administrators are completely blind when rate limits are exceeded, they cannot identify the offending integration or user, cannot proactively manage API usage across teams, and cannot troubleshoot production issues. This represents a significant feature parity gap from the Opsgenie → JSM migration that impacts operational reliability for customers who depend on API-driven workflows.

Workaround

Customers can inspect HTTP response headers (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset) on individual API calls and build their own monitoring/alerting around HTTP 429 responses and Retry-After headers. See:
Rate limiting. However, this approach is reactive, does not provide per-token/per-user breakdown, and does not offer historical analytics.