Skip to main content

Is Opsgenie Down?

No — Opsgenie is up

Reachable from all 8 checked regions

Average response time: 67ms

Last checked · checks run every 6 hours

Official status page: https://opsgenie.status.atlassian.com

Opsgenie uptime

100%
Last 7 days
100%
Last 30 days
100%
Last 90 days
128ms
Avg response, 30 days

Measured from multiple regions every 6 hours. Percentages count only checks that returned an availability answer — 10 days measured so far. A dash means that window does not yet hold enough measured days to publish a figure.

30-day history

10-day clean streak
Jul 28: no data
Jul 29: no data
Jul 30: no data
Jul 31: no data
Aug 1: no data
Aug 2: no data
Aug 3: no data
Aug 4: no data
Aug 5: no data
Aug 6: no data
Aug 7: no data
Aug 8: no data
Aug 9: no data
Aug 10: no data
Aug 11: no data
Aug 12: no data
Aug 13: no data
Aug 14: no data
Aug 15: no data
Aug 16: no data
Aug 17: 100.00% uptime, 16 checks
Aug 18: 100.00% uptime, 38 checks
Aug 19: 100.00% uptime, 32 checks
Aug 20: 100.00% uptime, 32 checks
Aug 21: 100.00% uptime, 32 checks
Aug 22: 100.00% uptime, 32 checks
Aug 23: 100.00% uptime, 32 checks
Aug 24: 100.00% uptime, 32 checks
Aug 25: 100.00% uptime, 32 checks
Aug 26: 100.00% uptime, 24 checks
Jul 28 Today
No downtime Partial Downtime Not measurable No data

Reachability by region

Each region runs its own request from a different part of the world. A service can be up for one continent and down for another, which is usually the first sign of a routing or CDN problem.

ams
50ms
DNS 0ms TCP 9ms TLS 10ms TTFB 49ms
lax
139ms
DNS 0ms TCP 30ms TLS 32ms TTFB 138ms
lhr
45ms
DNS 0ms TCP 4ms TLS 2ms TTFB 44ms
nrt
82ms
DNS 0ms TCP 3ms TLS 3ms TTFB 82ms
ord
120ms
DNS 15ms TCP 23ms TLS 26ms TTFB 120ms
sin
33ms
DNS 0ms TCP 2ms TLS 3ms TTFB 32ms
sjc
97ms
DNS 0ms TCP 21ms TLS 22ms TTFB 97ms
syd
36ms
DNS 0ms TCP 1ms TLS 2ms TTFB 35ms
yyz
79ms
DNS 0ms TCP 14ms TLS 15ms TTFB 78ms

What Opsgenie does

Opsgenie is Atlassian's on-call tool: it takes alerts from monitoring systems, decides who is on call, and escalates by push, SMS, email and phone until somebody acknowledges. It sits in the path of every other outage you have, which makes its own failures particularly awkward, because the system meant to tell you something broke is the thing that broke.

What an outage looks like

Alerts arrive in the web application but no notifications go out, so nobody is paged. One delivery channel fails while others work, commonly SMS or voice in a single region. Integrations stop ingesting, so monitoring tools report sending alerts that never appear. Heartbeat monitors expire and fire false alarms about healthy systems. Escalation policies stall midway through a chain.

What to do about it

Opsgenie's status page reports each delivery channel separately for the US and EU regions: email, SMS, voice and mobile notifications, plus alert and incident flow, heartbeat monitoring and the REST APIs. Match the failing channel there. If notifications are the affected part, watch the alert list directly and tell the on-call rota to poll it rather than waiting to be paged.

Is it down for everyone, or just you?

If this page says Opsgenie is up but it is not loading for you, the problem is between you and them. Run a check against any URL from all 18 regions to find out where it breaks.

Test it yourself

Related services

Opsgenie outage FAQ

Alerts show in Opsgenie but nobody got paged. What broke?
Notification delivery, not alert ingestion. Opsgenie separates taking an alert in from sending it out, and reports them as different components per region, so a channel such as SMS or voice can fail while the alert list updates normally. Until it recovers, treat the alert list as the source of truth and have whoever is on call watch it directly.
Are my heartbeat alerts real during an Opsgenie incident?
Treat them with suspicion. A heartbeat fires when Opsgenie does not receive the expected check-in, so an incident affecting heartbeat monitoring or integration ingestion produces expiry alerts for systems that are perfectly healthy. Confirm against the service's own monitoring before acting, and expect a cluster of these to resolve themselves when the incident closes.
Does an Opsgenie outage affect Jira Service Management?
Sometimes, because they share Atlassian infrastructure and some notification plumbing. Atlassian has reported incidents where voice notification delivery degraded for both Opsgenie and Jira Service Management customers at once. They are separate products with separate status pages, so check both when on-call paging and service desk notifications fail together.
How do we stay covered while paging is down?
Fall back to something that does not depend on the failing channel. Open the alert list in a browser and keep a person watching it, agree a group chat as the paging channel for the duration, and share direct phone numbers for the current on-call. If your monitoring can also post to chat or email directly, enable that path so alerts arrive without passing through Opsgenie.

How we measure this

  • We request Opsgenie's public endpoint every 6 hours from Fly.io regions across six continents — 8 of them answered the most recent check.
  • A region counts as down only when it gets no usable HTTP response. A 403 or 429 means the origin answered and refused us, which we report as blocked, never as an outage.
  • A single failing region is treated as probe noise. We only change the verdict when two consecutive cycles agree.
  • Response times average only the regions that actually served the page, so a timeout never inflates the number.
  • Where Opsgenie publishes an official status feed we read it too. An all-clear from the vendor can soften an unconfirmed degradation; a vendor-declared outage only worsens our verdict when our own checks corroborate it.

Get alerted when Opsgenie goes down

This page refreshes every 6 hours. Your own monitors run as often as every 30 seconds, from the same 18 regions, and tell you the moment something breaks.

Start Free Monitoring
Free plan available No credit card required