Datadog Reviews

The RUM is implemented for customer support session replays to quickly route, triage, and troubleshoot support issues which can be sent to our engineering teams directly. 

Customer Support will log in directly after receiving a customer request and work on the issue. Engineers will utilize the replay along with RUM to pinpoint the issue combined with APM and Infra trace to be able to look for signals to find the direct cause of the customer impact. 

Incident management will be utilized to open a Jira ticket for engineering, and it integrates with ITSM systems and on-call as needed.

The RUM solution has improved our ability to triage faster and hand more capabilities to our customer support.

The RUM is implemented for customer support. It can quickly route, triage, and troubleshoot support issues that are sent to our engineering teams. 

Customer support can log in and start troubleshooting after receiving a customer request. The replay and RUM help pinpoint the issue. This functionality is combined with APM and Infra trace to be able to look for the cause of the issue. Incident management is leveraged to open a Jira ticket for engineering, and it can integrate with ITSM systems and on-call as needed.

RUM with session replay combined with a future use case to support synthetics will help to identify issues earlier in our process. We have not rolled this out yet but plan for it as a future use case for our customer support process. This, combined with integrated automation for incident management, will drive down our MTTR and time spent working through tickets. Overall, we are hoping to use this to look at our data and perfection rate over time in a BI-like way to reduce our customer support headcount by saving on time spent.

I would like to see retention options greater than 30-days for session replay. I'd also like to see forwarding options for retention to custom solutions, and a greater ability to event and export data from the tooling overall to BI/DW solutions for reporting across the long term and to see trends as needed.

I've used the solution for about nine months.

So far, stability has been great.

I'd like to see more bells and whistles added over time. Widgets are coming soon to help with RUM.

Support is very good. They are responsive and gave us the help we need.

We have utilized New Relic, however, not for RUM. We went with Datadog to potentially switch the entire platform into an all-in-one solution that makes sense for a company of our size.

We started on the beta, and the documentation was lagging behind. We also needed direct instructions and links from the customer support/account representative that was not immediately available by searching online.

We implemented the solution ourselves.

Ideally, this will inform our strategy to not increase our customer support headcount as significantly into 2023 and beyond.

The pricing is a bit confusing. However, the RUM session replay, in general, is very inexpensive compared to whole solutions.

We looked into LogRocket and New Relic.

I'd advise other users to try it out.

After a security incident, we needed to find and migrate to a different cloud provider, and after evaluating different competitors and the skill set of the team, we decided to move to AWS. AWS also enables the team to have finer control over how our apps are deployed and how security and access are managed. By leveraging AWS's functionality, we have increased our application's security and sped up the deployment process. We've even been able to handle higher workloads due to AWS's auto-scaling functionality.

Elastic container services have improved our organization by allowing us to deploy our application. While this problem was not solved by using the elastic container service since we had a previous solution on a different provider, the ease and flexibility of deploys have greatly benefited the ops team and the overall engineering organization. It is easy to use. However, there are many out-of-the-box features like metrics and seeing task definitions that make life easier.

The most valuable feature I have found is the elastic container service. That is where our apps get deployed. This feature is really important to us since, without it, we would not be able to deploy our apps the way we wanted to and would have to use a different vendor. 

This service is also valuable to our team as we have a lot of familiarity with it and adapting to the services from our previous one was fairly seamless. 

Another feature that is very valuable for our team is the IAM. It allows us to control security.

ECS could be improved by including more tutorials for beginners to reduce the barriers to entry. It would help to ensure understanding and learning in terms of how to use a cloud provider. Besides this, there are not any other areas of improvement needed since the service is very straightforward and there is ample documentation.

I've used the solution for one year.

We use metrics to track the metrics of our application. We use logging to log any errors or erroneous application behavior as well as successful behavior. We use events to log successful steps in our pipeline or failed steps in our deployment. We use a combination of all these features to diagnose bugs. 

It makes it much more efficient to look at all the data in one place. This speeds up our development speed so that we can be agile.

This spectrum of solutions has allowed us to track down bugs faster and more rapidly, which allows us to limit revenue lost during downtime. 

It also allows us to accurately record and project current and future revenue by measuring the application's metrics. This way, my team can accurately and rapidly create reports for upper management that are easy to read and understand. 

Datadog is also easy to read by non-technical personnel. This way, if there are any erroneous readings, everybody has a chance to find them.

We use metrics to track the metrics of our application. We use logging to log any errors or erroneous application behavior as well as successful behavior. We use events to log successful steps in our pipeline or failed steps in our deployment. 

We use a combination of all these features to diagnose bugs. It makes it much more efficient to look at all the data in one place. This speeds up our development speed so that we can be agile.

These features are the features that I use the most since it is incredibly difficult to track down intermittent bugs if I were to look directly under the hood in a CLI.

Datadog could make their use cases more visible either through their docs or tutorial videos. There are different implementations of certain features that we utilize to customize Datadog functionality and in that way, we sometimes get results that are not conducive to what Datadog thinks their features' use cases are.

I've used the solution for at least one year.

We have only used Datadog. We did not previously use a different product.

Log aggregation for us was a key component since we have a fairly old-school app running on VMs on bare metal. We previously didn't have much insight into our logs unless we manually tunneled them into each server.

The solution is reducing manual labor in troubleshooting problems in our environments server by server.

We also needed to monitor our Java app and MySQL database to understand their problems so that we could take action and resolve them.

Our use cases have since expanded to encompass all aspects of monitoring.

Before Datadog, all we had to go on was the gut reaction of the old guard on our team. While useful, the reactions and inherent knowledge only benefited a few folks.

Datadog has allowed us to create comprehensive dashboards and proactively send out alerts. We used the knowledge of people very versed with our products to help set up the platform and have since benefited from that.

The operative word here is visibility, and we've seen a huge improvement in that.

Seeing log trends and patterns and aggregate search was a huge first step for us. We then began using other features of the Datadog platform by enabling APM. After that, we did other integrations.

For us to have visibility into our app stack and the hardware we run has been highly beneficial.

We leverage APM, log management, and at least ten other integrations. Our DB, web servers, network, storage, and other areas are now monitored and hooked up to dashboards.

Dashboarding has also proven useful when information is going to be viewed by anyone in the organization.

Our experience has been overwhelmingly positive so far. That said, there is one area that could benefit from some polish. For example, I want to applaud the efforts in making the UI extremely usable and approachable. My suggestion would be to take another look at how the menu structure is put together, however. Even after using the platform mostly every day for months, I still find myself trying to find a service or feature in the menus.

I've used the solution for around six or eight months. We've had the Datadog agents deployed on our various environments.

So far, we have not had any issues with stability. It should be very stable and easy to update.

The solution is currently deployed on a limited scale. That said, we see the potential and benefits of deploying this in a cloud scenario.

Customer service and the support teams have been very responsive when we need them. They are very professional.

Positive

This was our first solution in this space.

The initial setup steps with the agent are only confusing when using the config files for the first time. The main file includes a lot that you can specify elsewhere and it's not readily apparent which one to use until you dig in more.

We did an in-house implementation.

Our ROI with Datadog has been very high. It's given us the ability to see how we're performing, which we didn't have before.

Ensure you have your ingestion pipelines dialed in, or you'll likely spend more than you were expecting.

We evaluated free and open-source options, however, ultimately, we decided that we didn't have the manpower as a small company to maintain them.

There is nothing that the documentation cannot help with; it's very good.

We use the solution for monitoring time spent on views and events triggered. For example, for one of our products, we have created a custom dashboard that lets us track all the custom events and multiple entry points in the same part of the application.

Knowing the entry point helps us choose which part of the program should be improved next. It also helps us with collecting important data about the overall usage of each module within our application. 

The solution has helped our organization with custom events to track specific cases.

It's helped with monitoring time spent on views and events triggered. For example, for one of our products, we have created a custom dashboard that lets us track all the custom events as well as multiple entry points into the same part of the application.

Knowing the entry point helps us choose which part of the program should be improved. It's collecting important data about the overall usage of each module within our application. 

The most valuable feature is the custom events to track specific cases.

Monitoring time spent on views and events can be triggered. For example, for one of our products, we have created a custom dashboard that lets us track all the custom events and multiple entry points in the same part of the application.

Knowing the entry point helps us decide on improvements. We can collect important data about the overall usage of each module within our application. 

We look forward to the next features from Datadog. We need to learn more about the session reply feature inside of DD.

I've used the solution for two years.

We use the solution for logs from all our applications. In Datadog, for monitoring logs, our team creates an automation for implementing massive logging in all our systems. Now, we are deploying it in our core systems.

We are using it to indicate issues and alert our operations team. With this, we better monitoring of our applications and logs.

However, the main difficulty is implementing the solutions in our Kubernetes cluster, separated just as logs to the specific namespace as the volume of logs is tremendous.

The solution is useful for monitoring logs. 

We can create an automation for implementing across all our systems. Right now, we are deploying it in our core systems.

The greatest value is integrated monitoring as it is able to quickly detect issues and improve our time to market.

Our main challenge is implementing the solutions in our Kubernetes cluster, separated just as logs to the specific namespace since the volume of logs is tremendous.

I've used the solution for one year. 

We're moving towards the cloud yet still have several active data center contracts. As we move to the cloud, we are interested in knowing more about our services, and DataDog APM/logs should give us this perspective. 

We currently use the infrastructure monitoring part of DataDog. Still, I've really seen the advantage of moving more data into the cloud for comparison and being able to have one place where we can view all related pieces of information regarding a possible incident or potential issue.

We've been able to glean from the monitors what servers are down, and can alert the team in Slack. Knowing what we need to do next is what we would like to move to, so seeing the power of Notebooks is key. We also have several other services that we are underutilizing (logging, error tracking, etc.) that would be better housed in DataDog since it gives us more visibility into linking all of the things together into one cohesive picture.

Monitoring has been invaluable, and as we start to look to other products, bringing in logs and APM traces will create a full picture of what we need to do to resolve incidents. We're also interested in our users' perspectives and when things are slowing down for them.

Additionally, we are interested in the workflows announced today as an actionable decision tree that will allow our teams to see what is wrong and know what to do based on the connected runbook/notebook. I feel that this is the final piece that will make DataDog so much more valuable than its competition.

I have talked to vendors that mention that DataDog is drawing attention to an issue. However, you'll still need to take action on your own. The more tools that they can build that allow you to run AWX playbooks, or other similar fixes, would benefit clients greatly.

We've used the solution for two years.

I'm a Datadog partner in Brazil, and I monitor all my applications with Datadog too. I would like to enable all features in my DPN portal and get access to custom demos. We resell Datadog and a full stack of pre-sales, sales, and post-sales services. We have customers for all sectors, including governmental, financial services, services in general, telecom, et cetera. Today, we are the biggest Datadog partner in Brazil, and we are searching for an expansion in our MSP environment.

I resell all solutions in Datadog, so all features are important for our customers.
We are the biggest Datadog partner in Brazil, and we would like to expand our MSP environment.

The CCM, Workflows, Logs, APM, and RUM are all useful aspects of the solution. I resell all solutions in Datadog, so all features are important.

I'm a Datadog partner in Brazil, and I monitor all my applications with Datadog too. 

The solution works within all sectors, including, governmental, financial services, services in general, and telecom. 

We have contact with many customers that cover many areas, so we have cases where the infrastructure administration could be improved. In general, cloud users and microservices users like Kubernetes offer a faster improvement in the environment. Our users of the feature logs had a lot of benefits and found cost reductions also.

I've used the solution for three years. 

We used to use AppDynamics. We switched due to the fact that the cloud monitoring and K8 monitoring are not as good as Datadog.

I'm a reseller.

The licensing model is better, however, if they had the option to block consumption in the Infra and APM, that would help to keep better control of costs.

We did not evaluate other solutions.

We use the solution as a SaaS.

We primarily use the solution for observability, metrics, logs, tracing, and end-to-end user flow monitoring. 

We are looking to implement this as a company-wide standard for cloud solutions.

At this time, we're currently in a POC, and we're interested in using either a Datadog agent or the OTel agent with a Datadog exporter. We have dashboards with panels that correlate metrics and allow you to link through to traces. Flame graphs to show latency across services and the various spans. 

While we are not security minded, we still require it and are interested in more. It's used for monitoring critical systems.

It has provided visibility with ease of implementation and allowed multiple teams to quickly onboard it. This provided a standard way to approach observability and visibility. 

Monitoring rules and alerting thresholds can also be set and exported to other teams for use. 

There is an issue with federated dashboards, as multiple teams running on different Datadog instances cannot use features like the service catalog or easily switch between services in a long business flow.

The K8 monitoring is extremely useful in Datadog. Preset dashboards that it provides help to speed up the work. 

The metrics summary is useful. Tracing with a span breakdown is helpful for us. We like the dashboarding with power packs and logging correlation with traces and logs. 

The Flame graph for tracing helps determine where the latency is the highest. 

Dashboards are created as a standard set and then exported into other Datadog instances for other teams. 

These dashboards would be updated regularly and pushed out to the teams. Unfortunately, there is no way to automatically push or deploy code in a quicker way. Each team I work with has its own Datadog instance.

Federated views for Datadog dashboards are critical as large companies utilize multiple instances of the product and cannot link the metrics or correlate the metrics together. This stunts the usage of Datadog. Additionally, using an OTel agent would be more acceptable and allow for easier adoption of Datadog across the hundreds of teams here.

I've used the solution for four months.

We’re currently using logging, monitoring, metrics, APM, etc.  

We've started to use קSLOs. However, it takes a bit of time to work through those.

RUM (Real User Monitoring) has been very useful. I have used this in the past to debug problems in production, which has been great.

We also want to start using synthetics and tracing more. 

Our application currently runs in many different environments based on our customers' requirements. This allows us to see everything in one place and still filter by the environment as required, which is extremely useful. 

The solution has offered increased visibility via logging APM, metrics, RUM, etc. Going from almost nothing to something that didn’t take a lot of time to set up has been great since we have so little time to spare

As a startup, we have limited resources, and no one has enough time for anything. There are so many easy integrations and things configurable by YAML making everything easy to set up without needing a full-time employee. Just configuring monitoring solutions is very desirable. 

The APM is very useful for tracking down anything that’s gone wrong. I’ve been using it to make sure everything is working correctly after deployment, to make sure we don’t suffer performance degradation, and to track down anything that’s gone wrong in real-time  

The logs are great and necessary for any application. Before this, our solution would have been to SSH into a machine and tail log files. This is untenable for many reasons, and one of the first things I wanted to change.

The RUM is useful for seeing how real users interact with our website.

Sometimes it’s difficult to customize certain queries to find specific things, specifically with the logging solution. I’ve used other logging platforms in the past that have extensive and mature query languages, which might not be super friendly to start out with, yet they can be very powerful. I wish there was more of an emphasis on that instead of the UI-based tooling that Datadog provides. Even though it is powerful on its own, UI-based design lacks the elegance, efficiency, and complexity that something like that can provide. 

I've been using the solution for six months or so.

We did not previously use a different solution.

I don’t handle the licensing or pricing.

We did look into Splunk.