What is your primary use case for Catchpoint?

My main use case for Catchpoint is mostly automating. I use Catchpoint automatically for automated monitoring of our various UIs and also the backend APIs. We rely on Chrome and Selenium and JavaScript automation type.

My main use case for Catchpoint is to observe anomalies in the infrastructure. For example, when server memory gets exhausted, Catchpoint sends us a notification, and then we react to it and solve the issue. I use Catchpoint for multiple infrastructure alerts such as CPU, RAM, IOPS, and any application down, so I rely on it for multiple purposes.

My main use case for Catchpoint is synthetic monitoring. We use synthetic monitoring with Catchpoint to monitor the customer journey of our clients on our e-commerce sites, so we can proactively detect failures or errors that could affect our customer experience.

For Catchpoint, it has been a year since I have been using Catchpoint primarily for monitoring our Atlassian SaaS applications, specifically Jira and Confluence. Our monitoring focused on several key areas with Catchpoint. First was authentication, where we monitored login flows to ensure users could successfully authenticate. Second was page load performance, where we tracked how long important Jira and Confluence pages took to load. We also monitored functional workflows such as opening projects, navigating spaces, and accessing commonly used pages. Finally, we covered API monitoring to validate that important backend endpoints were available and responding within acceptable thresholds. We stimulated real user experience by using a service account that would log in to Jira or imitate the login workflow to check if the authentication login workflow is working fine with Catchpoint, and we used a browser-based authentication process. We primarily use it to monitor Jira and Confluence, including authenticated user journeys, page load performance, functionality, and API endpoints. We did not have to update Catchpoint monitors very frequently once they were stable. Most changes happened when the applications themselves changed. For example, when Atlassian updated the UI or changed page elements in Jira or Confluence, some of our synthetic monitors had to be adjusted because they relied on specific element locators. We would update the scripts or selectors, test them, and redeploy the monitor. Overall, it was a smooth process, although it did require some maintenance whenever the application changed significantly. Once the updates were made, the monitors continued to work reliably. When Catchpoint detects an issue, an email triggers to our team distribution list. The first step is for the alert to notify the operations team. We review the alert details and associated metrics to understand whether it is an availability issue, a slowdown in page load, a failed authenticated transaction, or an API performance problem. If the issue is confirmed, we investigate further by checking the affected Jira or Confluence service, correlated with application and infrastructure logs, and determine whether it is a temporary issue or something requiring immediate action. If needed, we escalate it to the appropriate application or infrastructure team. Once the issue is resolved, we verify through Catchpoint that the monitors are healthy again and close the incident. Overall, Catchpoint met our expectations. We used it to monitor Jira and Confluence, including authenticated user journeys, page load performance, and functionality checks. The monitors are reliable, and the alerts give us early visibility into performance issues before users report them. It also provides enough diagnostic information to help us identify where the shutdown or failure is occurring. For our monitoring requirements, it performs well and meets our needs.

My main use case for Catchpoint is that it does an excellent job in identifying the entire traffic patterns from the source to destination, and it also provides suggestions for a better path to reach the service much faster.A specific example of how I used Catchpoint in my previous organization is that we were primarily using it for monitoring our applications and endpoints in specific regions. We were looking for a BGP workflow where the AS group for a particular provider was a lengthier path than the suggested one. Catchpoint was able to identify the particular AS BGP peers and suggest that if we go through this path, it is the fastest way to reach our packets to our destination. The path we had associated with another ISP took a longer time for a response. These features helped us plan in a way that our monitoring improved, our detection time for a particular incident for that application was significantly improved, and we were able to pinpoint exactly where the problem was and come up with a better solution. Based on the suggestion from Catchpoint, the BGP AS number which was associated with it led us to change to a particular provider, which helped us in many areas like mean time to detect and mean time to recover. Catchpoint helped improve our numbers, and we were successfully able to integrate it with our internal tool, which gave us the right signal to initiate a war room, get the team on the call, and perform a quick troubleshoot and get those fixed as soon as possible. This helped us in many ways, especially our ability to monitor the services of our own application improved compared to waiting for a customer report. We were able to pick up issues much earlier and resolve them much faster.

My main use case for Catchpoint is to check website availability in different regions so that we can be aware of any downtimes. A specific example of how I have used Catchpoint to check website availability is when we check DNS propagation. We analyze how it is working and which locations it has propagated because sometimes clients reach out to us that a website is not available in a certain location, which could be due to DNS propagation. Catchpoint helps with those pain points, and we also use it to monitor when a website struggles on the CDN.

My main use case for Catchpoint is proactive monitoring of application performance, availability, and user experience. A quick specific example of how I use Catchpoint for monitoring application performance or user experience is that it helps us detect and resolve issues before they impact users, optimize service reliability, and monitor third-party dependencies. In addition to my main use case for Catchpoint, our use case includes synthetic monitoring, real user monitoring, API monitoring, and cloud/network performance tracking, ensuring seamless digital operations.

We are using this for an eCommerce product for live customers. This is used to monitor business performance, checking if customers are able to make payments on time or if they encounter issues during online shopping. If there are issues in a specific market, we can monitor the entire country and identify the frequency of issues. We wait for 15 minutes and, if the frequency increases, we take quick action.

I use the platform for endpoint monitoring, web page monitoring, and server activity tracking. It helps diagnose issues within networks, service providers, or local data networks.

We use Catchpoint to monitor our websites in real-time. It helps us keep track of various metrics.

Our primary use case for the solution is for end vision monitoring with an endpoint solution. We also use them to create network status while focusing on the synthetic solution because of digital monitoring. Catchpoint provides a great amount of information, and customers want budgets, so they spend less on cheaper products. Catchpoint has a better chance to increase its market, but they have been focusing on the synthetic force because there is a clear advantage and digital monitoring. We deploy the solution on-premises.

Our company tests versions of international websites for our clients and we use the solution's simple node backbone to track website response metrics and waterfalls. Our use case is unique because most companies conduct constant, proactive monitoring but we are responsive and only monitor when we experience issues.

We're using Catchpoint for monitoring activities. From a user perspective, we're using the tool to monitor online shopping customers and support global customers. Suppose customers face issues when purchasing, we get alerts from Catchpoint. Wherever there are red alerts, there are issues in specific markets, so these are the notifications we receive in Catchpoint. Through the tool, we can further drill down to see the flows we need to validate, and we can also see the input parameters the customers are using. We can also use Catchpoint to get test data in real time and validate those quickly. There are scatter plots in the tool where there are frequent drops or frequent notifications for specific markets, so we can just go over the scatter plots, see the time duration where we can identify, for particular markets, that the drops are consistent, and that would mean there aren't critical issues going on, so based on that information, we can take the actions we need.

Catchpoint is used for synthetic monitoring. For example, if you have a URL, you may want to ensure that your customer's journey is monitored from a user-experience standpoint. In Catchpoint, you can enter the user action, and that user action can then be configured as a script. Catchpoint will then continue to emulate that user's steps every 5 minutes or 10 minutes, as it is defined by you. If you have a service product and have just exposed the API in your data. In those cases, you can perform API monitoring by passing sample data contracts and validating whether your API is responding to the query or not. It can also tell you what the time is, what the response score is, and so on.