You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
Update: Our AMA with @Serhat Can is complete! Thank you everyone for taking the time to write your questions and participate, you are the folks that make the community enriching and fun! If you still have questions or thoughts, we'd love to see them in the Opsgenie Collection and we will answer them as soon as possible.
Thanks again for your participation, it was great chatting with you all!
Serhat & Kate from the Opsgenie Team 😀
Hi there Community!
My name is Serhat Can and I’m a Technical Evangelist for Atlassian with a focus on Opsgenie, as well as an AWS Hero and DevOps Days Core Organizer.
I began my career at Opsgenie in Turkey as an engineer building and operating products as part of the Opsgenie Team and now I focus on technical evangelism and helping teams build better on-call and incident response practices.
On Thursday, July 18 starting at 6 am. PDT I’ll be hosting a real-time AMA to answer your questions about Opsgenie, DevOps, On-call culture, and best practices for Incident Response.
Here's how it works:
Add your questions below any time before or during the AMA. Be sure to take a look at other community member’s questions and up-vote those that you find interesting.
This AMA is TODAY! Watch the page for answers and feel free to provide follow-up questions and discuss further with other Community members. We'll wrap the event at 8 am PDT, but will be sure to answer any questions we didn't get to.
Some example questions might include “How do I prepare for On-Call?” “What are best practices for incident response in Opsgenie?” “How does my company work to achieve a better uptime statistic?”
See you there,
I am curious to hear about some interesting user case examples, before and after Opsgenie was implemented.
Hi! This is a great question, we're currently working on adding various Case Studies to our website, but here are some videos done with customers that are a great way to see some use cases:
AWS has just superseded CloudWatch Events via the API compatible Amazon EventBridge the other week, with the notable extension of partner event sources to "make it easy for our customers to integrate their own AWS applications with SaaS applications".
Given one of the early partners is PagerDuty, I hope and expect Opsgenie is going to follow suit, can you already share anything about your respective plans?
Hey again Steffen!
We are already working on an integration with Amazon EventBridge :)
A side note, EventBridge uses the same underlying structure with CloudWatch Events but it is a completely new product - at least for now.
Most excellent, thanks for the confirmation :)
You are right of course that "EventBridge builds upon and extends CloudWatch Events" by using "the same service API and endpoint, and the same underlying service infrastructure". I've just tried to come up with a phrase to quickly convey that users only need to use EventBridge going forward, as per the related FAQs, e.g.:
Q: I currently use Amazon CloudWatch Events and I WANT to try the features of Amazon EventBridge. Do I need to move my Amazon Cloudwatch Events rules and permissions to Amazon EventBridge?
No. Existing Amazon CloudWatch Events users can access their existing default bus, rules, and events in the new Amazon EventBridge console and API or in the Amazon CloudWatch Events console and API.
Q: Are you going to deprecate Amazon CloudWatch Events one day?
No, we are not going to deprecate the API or the service itself. Amazon EventBridge is using the same API, and has added additional features. Over time, the Amazon CloudWatch Events name will be replaced with Amazon EventBridge. [emphasis mine]
I've now replaced 'rebranded' with 'superseded', even though that still doesn't sound 100% accurate.
We are facing that very question within Utoolity's Automation with AWS apps btw. - our existing Put Cloudwatch Events action works out of the box with Amazon EventBridge, and we are currently discussing whether renaming or duplicating is the best way forward usability wise.
Makes sense, thanks for the detailed explanation. I didn't see the "will be replaced" note before.
Looks like even though the recommended way is to use EvenBridge from now on, it will take some time before people start using it. So, I think I'd be more on the duplicating side :)
Opsgenie has recently introduced Incident response with AWS Systems Manager by providing AWS Systems Manager Actions. While one of the benefits of AWS Systems Manager Automation is the ease of creating and maintaining SSM Automation documents tailored to custom scenarios, the AWS community also benefits from the many readily available SSM Automation documents provided by AWS, which cover common scenarios on their platform and ease getting started accordingly.
'Incidentally' one of the available automation documents is AWS-CreateJiraIssue, which makes me wonder whether the Opsgenie team is considering a similar collection of readily available SSM Automation documents that cover common scenarios for the Atlassian community?
For example, I'd consider the following Atlassian workflow actions applicable to incident management:
Ah yes, one should also be able to create an endless loop of course ;) (those are more the other side of the coin, making it easy to manage Opsgenie alerts via AWS workflows):
Of course, I can create any of these myself today, but having the core Atlassian product actions readily available would likewise simplify integrating Atlassian products into AWS automation scenarios.
I definetely see your point. I talked with Opsgenie product managers. They are aware of this and they will soon explore more with the AWS team.
Personally, I think these are great suggestions to better integrate with SSM for all relevant Atlassian products.
@Serhat Can : Super awesome AMA ! I am a complete Ops Genie n00b... we don't use it in our company (we're way too small and not "busy" enough... however, that will change in the coming year hence my question:
When is the right time during an organisations scale up to introduce Ops Genie?
We're a company of 25 whereby we have 1 person logging in daily to Jira and development teams using it sparingly (1 major project per year).
Due to a major acquisition we're forecasted to grow to 50+ people in the coming year, with 10 complex and challenging projects per year!
@Andy - PTC Redundant , thanks for asking this great question! And it is nice to hear your company is growing :)
Before I answer your question, would you mind telling me how many of you are responsible for running always-on services on production? or in other words, how many people get alerts and try to fix them when something is wrong?
We have two project managers, two UX/UI/3D designers, two engineers and thirteen developers that have to respond on alerts. (With devs responding the most)
The PMs are responsible for ensuring smooth running of everything.
First, any company that has a service running all the time needs Opsgenie. Now I assume you have at least one, possibly a dozen soon :)
I think there is one very important factor in deciding when to start using Opsgenie: monitoring.
Do you monitor your services? If not, start there and have some visibility into your infra, services, and connections between services through metrics, logs, and traces. Those visibility endpoints can be used to show if something is going right or wrong. If something is wrong, create an alert. Once you get alerts for problems, you can use Opsgenie.
Opsgenie offers many benefits over simple alerting provided by many monitoring solutions. Most important ones are making alerts actionable, routing them to the right person at the right time, ensuring critical alerts are never missed and gaining insight into areas of success and opportunities for improvement. I won't go into the details because that means going over product features. More info here.
Considering your answer to my earlier question, I'd like to add one important note. It seems like there will be multiple teams with multiple members going on-call. Opsgenie has many features to better support multiple teams and services use-case. Team admins can manage their integrations, on-call schedules, escalations, and services. This gives them the autonomy they need to move faster.
We have customers with a couple of users to thousands of users. Each one has unique use-cases and needs. Opsgenie is flexible enough to support many use-cases natively. We also have almost everything available through APIs that help customers to cover their specific needs.
Hope this answers your question.
Thank you, Serhat.
I'm in the early process of setting up on call management for my company so just had a quick question about benefits of utilizing OpsGenie over other vendors. What does OpsGenie do particularly well versus other solutions like Pagerduty or Victorops?
Many thanks for the help!
Hi Daniel, welcome to the Atlassian Community and thank you for your great question!
We have Opsgenie vs Pagerduty and Opsgenie vs VictorOps pages that I think answers your question from a features perspective. Let me summarize some important differentiators of Opsgenie versus other solutions in the market:
These are just some of the obvious advantages. If you need more detailed explanation or a demo, you can reach out to customer success team on the contact us page.