Datadog Reviews

We primarily use the solution for the RUM, security monitoring, and streams.

We need to monitor users and what they access. We also need to identify security loopholes and attack patterns and identify and quickly respond to issues.

We can identify pushbacks, and get insight into application components that stack up with each other. We can understand which components, libraries, and code to alert teams.

Using Datadog, we can raise incidents, track incidents to completion, and be able to gather data for reporting and post-mortem.

The solution allows us to track fixes and tracks their test coverage. With it, we get confidence in the fix/improvement phase and be able to provide a response.

The solution has improved the organization by providing good insights into app performance and offering good dashboards.

With it, our company can track fixes and track test coverage. We get confidence in the fix/improvement and are able to provide a response.

I've been able to present data to the team/ management based on the team's dashboards.

It's helped us when we've needed to monitor users and what they access or needed to identify security loopholes and attack patterns. It can help identify and quickly respond to issues.

Datadog allows us to identify pushbacks, and get insight into application components (how they stack up with each other). When we need to know which component, libraries, code, and teams to alert, we can raise and track incidents to completion and gather data for reporting and post-mortems.

The APM and container monitoring are excellent aspects of the solution.

It helps with monitoring users and what they access.

We can identify security loopholes and attack patterns while quickly responding to issues.

Our team can now identify pushbacks and get insights into application components. We can gather data for reporting and post-mortem, and we can track fixes and test coverage. Datadog allows us to gain confidence in the fix/improvement.

I've been able to present data to the team/ management based on the team's dashboards.

We'd like Datadog to make the log storage cheaper. Right now, it makes our life difficult since logs are stored separately.

We should not have to rely on team members to educate themselves in Datadog features. There should be templates that anyone can select, and they should be able to create dashboards easily. This is really slowing us down. It takes time to to explore the full potential of Datadog.

I've used the solution for two years.

We use Datadog for observability and monitoring primarily. Various cross-functional teams have built various dashboards, including Developers, QA, DevOps, and SRE. 

There are also some dashboards created for senior leadership to keep tabs on days to day activities like cost, scale, issues, etc. 

Also, we've set up monitors and alarms that kick off when any metrics go beyond the threshold. With Slack and PagerDuty integration, correct team members get alerted and react to solve the issue based on various runbooks.

Using Datadog metrics has helped the organization a lot in many manners. With one centralized monitoring place, it's a lot less effort to keep track of the system and applications' health. 

Using this also helps teams be proactive in dealing with any issues before they get escalated by customers. 

Lastly, having so many integrations makes the DevOps and SRE's lives a lot easier when automating the detection and resolution of any issues hidden in the system or applications. Overall, it has helped a lot.

My favorite feature is creating dashboards as that empowers me to sleep calmly at night and not to keep watch on critical system metrics. Be it DB metrics or computer-related metrics, it's always easy to view them. 

The ease of correcting these dashboards and widgets when needed is amazing. 

The only issue I face is when more than one person editing these dashboards simultaneously, one or the other person sometimes loses his/her work. That said,  they will resolve that soon. With the variety of widgets, it's so easy to plot the data in a timely manner, and that makes monitoring a lot easier.

The solution can be improved in a few areas. 

The parallel editing of the dashboards should not cause users to lose the work of another person. 

Secondly, we would like to see more demos of tools that are in beta version, when they come live. I am sure they will help us a lot.

I've been using the solution for slightly over two years.

I find the solution to be very stable.

I totally love it. It is scalable. 

We previously used Sumo Logic.

The initial setup is not so difficult.

We implemented the solution in-house.

The ROI is very fair so far.

I can't recommend the licensing.

I was not involved in any pre-evaluation process.

We use Datadog for observability and system/application health, mainly for product support, triaging, debugging, and incident responses.

We use a lot of the logging and the Datadog agent to collect logs, metrics, and traces from our GKE workloads. We use APM and continuous profiling for latency and performance measurement. We use RUM to observe frontend user events, such as tracing on request and what actions they take before errors occur. We also use error tracking and source maps to debug production failures.

We are still relatively new to the product, and we are planning to use more of the notebook functionality and power packs to record run books and break knowledge silos. We also need to utilize dashboards and continuous profiling more for performance measurement and integrate Datadog alerts for incident response.

We have way more observability than what we had before - on the application and the overall system. That includes the GKE cluster, nodes, and pods. It's helped with our cloud-run instances, databases, and data storage.

We also started observability in the CI pipeline to measure our CI performance, as it was a pain point for us. We are aiming to do incremental deployments and releases, and the bottleneck so far has been our CI performance. The visibility on which actions or functions take the most time allows us to pinpoint and focus on improving configurations on these.

We use structure logging a lot to triage production issues. The querying, attributes and tags manipulation, and customization have been very helpful in isolating and filtering environments. The integration with Winston logger has also been a breeze.

First and foremost, was that structured logging, tags, and attributes have not only allowed us to narrow down to a problem quickly in production, they have also let us create dashboards from these logs to understand more user behaviors, such as how many users stop and leave our application before an upload has completed. That helps us understand how important processing time is to a user.

We also intend to use distributed tracing more to understand where the error has occurred in a particular request.

Definitely, documentation could use improvement. As I navigated and try to find instrumentation and implementation details, I discovered inconsistency among SDKs based on languages. 

There are also places where highlighting can be improved. I once created an issue on GitHub, and it was resolved right away by an engineer. He pointed out that it was actually in the documentation. I looked again and found it was not very obvious. We were stuck on the problem for days.

Auto instrumentation on tracing has not been very easy to find in the documentation. We ended up using OpenTelemetry, yet the conversion between tracing contexts has been difficult.

We've used the solution between six months and a year. 

Customer service and support are generally very fast. I did experience one ticket, which involved changing the log index retention period, not being responded to. Any support tickets related to technical issues were resolved pretty fast.

Positive

We used to use GCP Stackdriver for logging and monitoring since our infrastructure is all GCP based. It was lacking a lot, particularly on tracing and structured logging. We often had a lot of trouble triaging and diagnosing a production problem. Datadog's specialty is observability. Since we started using the product, we were able to create dashboards, and utilize APM, continuous profiling, RUM, and distributed tracing for production support and user trends.

Datadog also offers labs and workshops for its products, which is very helpful.

We implemented the product ourselves.

I'm not sure what our ROI would be.

We started with on-demand pricing as we were re-writing our product, and we weren't sure about the total usage. After we went into production and released the product, we experienced a price surge. Fortunately, our Datadog account manager reached out to us and suggested a monthly subscription, which is what we'll be switching to.

I'd advise keeping an eye on the usage and possibly setting up some monitoring on price. We didn't have much of a setup cost; we started with a free trial and continued with on-demand after the trial ended.

We didn't evaluate many of the other options. However, we do also use OpenTelemetry, which is vendor agnostic and integrates with Datadog.

We always keep the Datadog agent to the latest version.

We primarily use Datadog for logs, APM, infrastructure monitoring, and lambda visibility.

We have built a number of critical dashboards that we display within our office for engineers to have a good understanding of the application performance, as well as business partners to understand at a high level the traffic flowing through the app.

We started with logging, as our primary monitor, and have shifted to APM to get a deeper understanding of what our system is doing, and how the changes we are making impact the apps.

Datadog has given us near-live visibility across our entire cloud platform. We are finally in a state where we are alerting our users about degraded performance well before the helpdesk tickets start rolling in.

We are making major architectural decisions based on the data we are getting from Datadog. It also gives us an idea of where the complexity really lies in some older, monolithic apps. 

We have used the APM endpoint monitoring to prioritize work on slower endpoints because we can see the total count, as well as the latency. That has been a big driver in our refactor work prioritization.

We have struggled to get more business-centric measures in our code to surface actual business values in our reports, but that is our next initiative.

We started with Log analytics in the beginning stages of our monitoring journey. Those were very insightful, but obviously only as useful as we made them with good logging practices.

The dashboards we created are core indicators of the health of our system, and it is one of the most reliable sources we have turned to, especially as we have seen APM metrics impacted several times lately. We can usually rely on logs to tell us what the apps are doing.

APM and Traces have been crucial to understanding how users are actually using the app. That drives a lot of our decisions around refactoring and focusing our limited engineering resources.

Continued improvement around cost and pricing model is needed. It is pretty complex and takes a fair amount of intimate knowledge to know exactly how turning on a single function is going to impact your bill, especially when you don't see the metrics for a day or two. 

We have recently had a number of issues with stability and delays on logging, monitoring, metric evaluation, and alerts. More often than not in the past month, it seems that we get the banner across the to of our dashboards that some service is impacted. They don't always show up on the incident page, either.

We have been using Datadog for two years.

Overall, it has been fairly stable for us. There are the occasional issues with importing data, that has usually been resolved in a short time. We have never had an issue where that data was lost, just delayed, and eventually backfilled. 

It seems (anecdotally, of course) that there have been a few more stability issues lately. We have noticed several days that we are getting in-app alert banners indicating that some metric or log ingestion was delayed, or the web app itself was experiencing severe slowness. 

Overall, these issues are resolved rather quickly - kudos to their engineering teams. I hear that they actually use Datadog to monitor Datadog. 

Datadog is very scalable but just watch the cost.

Technical support is hit and miss; there are a number of nuances to how this tool should be implemented, and it is difficult to re-explain how our infrastructure and applications are set up every time we need an in-depth investigation to understand what is broken.

Previously, we used AppDynamics. The pricing model didn't seem to fit with actual cloud spend. Now we may have swung the pendulum a little too far, and seem to be dealing with pricing on every facet of the application. 

The initial setup was pretty straightforward. Additional tweaks and configuration have been a bit more difficult as we get deeper and deeper into the guts of the integrations. Making sure we are keeping up with a rapid release schedule, and keeping our server clients in sync with our app packages has been troublesome. There have been some major changes in the APM that have introduced a number of bugs and broken some of our dashboards and alerts.

Our in-house team handled the deployment, with a lot of tickets created for the Datadog team.

ROI is difficult to measure completely. Our first year spend compared to our second and now going into the third year spend have been significantly different.

My advice is to really keep an eye on your overage costs, as they can spiral really fast. We turned on some additional span measures and didn't realize until it was too late that it had generated a ton.

Frankly, we love the visibility it gives us into our applications, but it is a bit cumbersome to ensure we are paying for the right stuff. Overall, the cost is worth it, as it helps us keep system-critical applications up and running, and reduces our detection and correction times significantly.

We evaluated Dynatrace and AppD before choosing this product.

Datadog requires pretty close supervision on the usage page to ensure you aren't going out of control. They have provided a bunch of new features to assist in retention percentage, but it can be a bit confusing on what is being retained, and what can be viewed again after triggering an alert. It's a difficult balance of making sure you are getting the right data for alerts, and still having the correct information still available for research after the fact.

We were in need of a cloud monitoring tool that was operationally focused on the AWS Platform. We wanted to be able to responsibly and effectively monitor, troubleshoot, and operate the AWS platform, including Server, Network, and key AWS Services.

Tooling that highlighted and detected problems, anomalies, and provided best practice recommendations. Tooling that expedites root-cause analysis and performance troubleshooting.

Datadog provided us the ability to monitor our cloud infrastructure (network, servers, storage), platform/middleware (database, web/applications servers, business process automation), and business applications across our cloud providers.

Datadog provided us the tooling to help us effectively monitor, troubleshoot, and operate the AWS platform, including Server, Network, Database, and key AWS Services. It highlights detected problems and anomalies and provides best practice recommendations, expedites root-cause analysis, and performance troubleshooting.

Datadog provides analytics and insights that are actionable through out-of-the-box visualizations, dashboards, aggregation, and intuitive searching that shortens the time to value and account for our limited time & resources we have to operate in production.

The most valuable feature is the dashboards that are provided out of the box, as well as ones we were able to configure. Specific Dashboards that were provided that made things easier were EC2, RDS, Kubernetes dashboards.

We also use the logging tool, which makes searching for specific error logs easier to do.

Datadog Logging provides the capability for us to use AWS logs such as VPC Flow Logs, ELB, EC2, RDS, and other logs that provide lots of relevant operational data but are not actionable. Datadog provides a tool that can provide us analytics and insights that are actionable for visualizations, dashboards, alerting, and intuitive searching.

More pre-configured "Monitor Alerts" would be helpful. Datadog's knowledge of its customers and what they are looking for in terms of monitoring and alerting could be taken advantage of with pre-canned alerts. They have started this with "Recommended Monitors".  That feature was very helpful when configuring our Kubernetes alerts. More would be even better. 

Datadog tech support is very good. One area that could be more helpful is actually talking to someone or sharing your screen to help troubleshoot issues that arise. For new cloud engineers just coming into the cloud monitoring field, there is a learning curve. There is a lot to learn and figure out. For example, we still ran into some issues configuring the private link and more videos of how to do things could be of use.

We have been using Datadog for one year.

We have not run into any issues with stability.

The scalability of Datadog is very good.

Customer service has been excellent.  I communicate weekly a Datadog Customer Success Manager.  He helps me followup on any open issues or questions that we may have.  Technical support has been very good. Opening tickets is easy.  Sometimes a Tech Engineer may take a bit of time to get back with you.  Communicating with Tech Engineer has to be done via ticket/email - no phone assistance is available.

we did not.

Procedures for setup seemed straightforward but once you got going, there were some issues. For us, getting our private link to work needed additional tech support. They were able to help us resolve the issue we were experiencing. I think the procedures could be done a bit better to help you with setup.

We deployed it ourselves.

Datadog helps us minimize downtime and helps us resolve issues quickly.  

Pricing seemed easy until the bill came in and some things were not accounted for. The issue may have been that we didn't realize what was being accounted for, such as the number of servers and the number of logs being ingested.

Datadog had really good pre-sale reps that work with us but need to make sure all the details are covered.

The solution we were looking for needed to provide out-of-the-box capabilities that shorten the time to value. We had limited time & limited resources. Datadog had high recommendations in these areas, so we decided to do a trial with them.

We are very pleased with Datadog overall.

Datadog has assigned an account rep to us that meets with us regularly to make sure all our needs are being met and help us get answers to any questions or issues we are running up against. They have been of great helping us standup monitoring of our Kubernetes environment.

Datadog is expensive. 

The tool's deployment is easy. 

The solution's pricing depends on project volume. 

I rate Datadog a seven out of ten. 

We use actual user monitoring and have set up thresholds for alerts to PagerDuty, Sentry, Slack, and so on. We also have dashboards set up for tracking latency and error rates. 

As an individual contributor, I also try to set up dashboards for the individual feature projects I work on. I'd like to learn more ways to use this, though, especially when it comes to more proactive approaches to issues. A starter pack of common-use types would be nice.

The solution it has improved our organization by expanding the awareness of issues and alerts beyond SRE and really empowering software engineers at a team level to make changes to monitoring and incident responses.

There could still be more training to bring this even further. A lot of the time I get into Datadog and it's already an incident and I am not in the right mindset to learn about the product or set alerts up.

The feature I have found most valuable is when I can reuse existing monitors and alerts for new dashboards. 

It is nice that things are so integrated, and any individual thing I build out can likely be re-used across the suite.

Other features I have found useful include the stack traces, especially when it links back to something specific I can look for in the code base. I also like that you can group similar alerts together to look for trends over time instead of one in isolation and see if there have been regressions.

The biggest improvement would be around educational content and helping new users get started. I've only been using Datadog for a few months, and at first, it was frankly overwhelming in terms of both the UI and the available capabilities. The workshops today have helped with this, however, more could be done.

As a user, I have about six or more months of experience with the solution. As a company, I'm not sure.

I was not in charge of evaluating any other solutions.

We use the solution for monitoring our logs across distributed clusters. Right now, we have an Elasticsearch solution that is tied to each platform (our product is a PaaS solution). 

We are looking at moving to a single pane of glass solution, which Datadog would be good for (plus, we could wrap up other tools like Prometheus, Grafana, Pagerduty, Pingdom, and more). We want to be able to have Datadog running on one single cluster and ingesting and processing logs from all our distributed clusters.

So far, we are just in the evaluation stages so it's hard to say how it's improved out organization. However, one positive impact it had is it's been just showing us an example of how to build in observability, metrics, tracing, etc., in a better way. 

Even if we don't end up using Datadog, it revealed problems and optimizations to us that weren't obvious before. One potential reason why it may not help us is that we have strict rules around log parsing and may not be able to send it to an external organizaton for ingestion/processing.

The CPU profiler has been interesting even though it isn't our core use case. 

We are finding that Datadog has way more offerings than originally expected, so we are constantly finding new parts of it that would be convincing to use. 

The log and ingestion are very similar to our current Elasticsearch setup. We find the tracing and overall integration/ecosystem to be the most valuable part. Basically, the CPU profiler is a good example of a value add for a problem we knew we had yet was low priority and had hacky workarounds. The value proposition is in the ecosystem as a whole.

The sheer amount of products that are included can be overwhelming. 

The solution requires better overarching UI, which would make things clearer. Even though I generally dislike the AWS UI, it makes the different services very clear, and it also makes where you are at any given point clear. 

The sidebar for all the different services is a bit much. 

I also found the tagging of logging pipelines to be a bit tedious. It would be great if, once marked up, it would automatically be a first-class citizen in Datadog.

We are still in the evaluation stage and have used it less than one month.

The stability looks good so far.

It seems easier to scale and build app functionality across multiple teams rather than other solutions.

We have used Elasticsearch, Grafana, and Prometheus. We are still evaluating Datadog.

The product has provided good ROI by saving development time as well as time managing setting up ES.

It is somewhat expensive compared to open-source options.

We evaluated Elasticsearch, Grafana, and Prometheus. We are still evaluating Datadog.