Datadog Reviews

We primarily use the solution for logging and APM, and for real user metrics.

The solution has helped out organization gain improved visibility.

The most useful aspects of the solution include RUM, session replay, and APM.

The product needs a better Datadog agent installation.

I've used the solution for one year.

We previously used App Dynamics.

Before choosing Datadog, we looked at Splunk.

The product is primarily used for the DevOps team. 

It has helped us build pipelines for ops review and other functions.

Datadog is providing efficiency in the products we develop for the wireless device engineering department. We had to provide more developer integration tools and also needed to help in creating easy queries that would help in creating efficient toolsets for management to make decisions based on these metrics.

We need more integration functionality, including certain metrics integration. We should be able to monitor devs and need it to build more monitoring tools and offer leadership metrics.

I've used the solution for almost six months.

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.

We use different tools for log collection and monitoring. Using Datadog will combine different use cases into one product that will be easier to manage. 

The tools we use are open-source, so there is no commercial support. Having customer support would be ideal since we're a small team. 

Profiling would be another great feature to have. Currently, it's manual. Having Datadog would give us a standard, and we don't have to do much manual work.

It will solve a lot of our problems. We have different tools for each of them in our organization; they are open-source and therefore not very well maintained with there is no customer support. 

Having an industry-standard product such as Datadog would be ideal for us as we are short on manpower. Since this is a managed all-in-one product with readily available support, we will be able to focus on application logic rather than figuring out why a tool isn't working.

The biggest thing I liked was the combination of all the things - monitoring, log aggregation, and profiling. We have different tools for each of them in our organization and all of them are open-source. These are not very well maintained and there is no customer support. 

Having an industry-standard product is ideal for us as we are short on manpower. Profiling is another amazing feature. Currently, we rely on some open-source solutions, and it's all done locally. Having it done on Kubernetes would give us more insights and help with performance. Alerting is again a nightmare for us. Datadog solves all of these issues.

It can be overwhelming for new people as it has a lot of features. The UI could certainly be improved. Having less information with better organization could help newcomers. I haven't seen the documentation, however, a well-organized documentation would invite many varied users.

I've been using the solution for three years.

We are using Datadog for server metrics, log aggregation and searching, system monitoring, alerting the team about errors, and dashboards for our developers. It's used by the Site Reliability Engineering team and Management of all levels. 

It's assisting us in proving SOC II compliance. 

We're looking to improve our usage of Datadog's RUM and APM components to get better and more performance insights on our production environments. 

We're also looking to leverage more synthetic monitors and runbooks for anyone responding to incidents.

The ability to easily drill down into log queries quickly and efficiently has helped us to resolve several critical incidents so far this year, and we heavily rely on a series of dashboards showing us various queues and load on CPU and memory for servers. 

We also have a view of the information required when we begin the patch and/or upgrade processes. 

I've also set up several monitors to alert the Site Reliability Engineering team when various metrics show a server might be reaching capacity. We use it to send an email suggesting we increase the size of the cloud instance.

The ability to easily drill down into log queries quickly and efficiently has helped us to resolve several critical incidents. We heavily rely on dashboards that are showing us various queues and load on CPU and memory for servers. 

We also have a view of the information required when we begin the patch and/or upgrade processes. 

I've arranged several monitors to alert the Site Reliability Engineering team when various metrics show a server that might be reaching capacity. We use it to send an email suggesting we increase the size of the cloud instance.

Datadog could always lower the price! In general, more demos online and maybe more free hands-on tutorials for basic functionality would be good for less technical users. 

I would also prefer more chances to amend the contract more than twice a year. As a smaller but growing company, it can be difficult to adequately predict demand.

I've used the solution for more than three 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 mostly use it to handle log aggregation, monitor our web application, and alert us on data pipeline failures. 

Our system is fully on AWS, and so we pipe in all of our Cloudwatch logs into Datadog to have a central place to index and search logs. 

Our web app is built on an Elastic Beanstalk backend, and we use the Datadog agent to keep track of all of the requests that hit our backend and all of their components. 

We also use the prebuilt AWS pipeline dashboards to monitor our batch jobs and lambdas.

Datadog has made it much easier to have a central place for people to look for logs and made it much easier to notify them of any elevated error rates or failures. 

It is also easier to get high-level views of platform health, whereas looking directly at AWS tends to provide very specific insight into particular surface areas or products. 

By having the whole team onboard onto Datadog, we also have a single source of truth that everyone can use when triaging and resolving incidents that occur across any surface area.

The ease of setting up metrics and alerting and integrating with Slack has significantly reduced the friction of keeping the team up to date on the platform's health. Before creating custom Cloudwatch metrics was never very intuitive, and also it was non-trivial to set up integrations with other services we use, especially Slack. 

It also provides a good way to gain the context needed when trying to fix issues, as it's a central place to look through logs, requests, AWS metrics, and more - overall contributing to the health of our platform.

The product is quite complex, and there are so many features that I either didn't know about or wasn't sure how to use.

One thing that could be improved is somehow surfacing interesting or relevant products that might be applicable given our infrastructure. 

Additionally, the billing can sometimes be confusing and opaque, especially around not making it obvious what the implications can be if you add different AWS integrations. This has caused some unexpected costs in the past due to engineers not understanding how Datadog pricing works.

We've used the solution for around two years.

This was the first solution we tried.

It is quite expensive, especially if you don't know how the pricing works.

We primarily use DataDog for performance and log monitoring of cloud environments, which include VMs and Azure Services like Azure compute, storage, network, firewall, and app services via event hubs.  

Alerting based on monitors via teams and PagerDuty. 

Logs collection for Azure services like Azure database, Azure Application Gateway, Azure AKS, and other Azure services.

Custom metrics using a Python script to collect metrics for components not natively supported by Datadog.

Synthetic testing to ensure uptime and browser tests via CI/CD pipeline.

Datadog has improved our visibility into infrastructure topology and performance. It provided a simplified view and ability to drill down to system performance, process usage, and logs.

We were able to set up monitors for infrastructure and applications, as the metrics were readily available in the platform. Fine-tuning monitors is very easy and the ability to configure monitor alerts with details on how to resolve the alert is a key value add. 

Integration with PagerDuty, teams ensure timely alerting. PagerDuty integration bring tags from Datadog to PagerDuty, which is very useful in routing incidents to the right service

The Host Map, Live Process provides performance metrics of our application. The support team likes using Datadog for identifying resources affected and obtaining the logs. 

Monitors are easy and quick to setup. Metrics are easily accessible and quick to use. The ability to send notifications based on metadata from the monitor is helpful. The setup for monitors is one time and it works for all workloads, whether it is Azure or any other cloud.

Logs rehydration helps us archive and rehydrate logs as we need. We don't need logs to be indexed at all times. Logs are required only for escalations and rehydrating does the job and provides cost savings.

We need the ability to create a service dependency map like Splunk ITSI. We have to build this in PagerDuty and it's not the best user experience. The ability to create custom inventory objects based on logs ingested would be a value add. It would be better if Datadog makes this a simple click and enable.

It would be helpful to have the ability to upgrade agents via the Datadog portal. Once agents are connected to the Datadog portal, we should be able to upgrade them quickly.

Security monitoring for Azure and Operating System (Windows and Linux) are features that need to be addressed.

Dashboards for Azure Active Directory metrics and events should be improved.

We have been using Datadog for more than six months.

Stability-wise, it has been good.

The scalability is good so far. 

Support team has been very responsive. Only complain is on issues they don't understand, they should have a quick call and unblock the customer.

We didn't have a solution in place. The only thing we had were logs.

Setup is hassle-free and pretty straightforward. 

I deployed it myself.

No returns yet. We are in growth mode. If this becomes expensive we may have to look at alternative options.

The cost is high and this can be justified if the scale of the environment is big.

Datadog needs to provide better pricing for large customers.

Prior to implementing Datadog, we evaluated Splunk.

Overall, the Datadog product is really good.

It doesn't need a sales team and yet, the sales team has screwed up on some occasions. It's a great product and the customer success needs to put an extra effort to help customers with best practices rather than passing them off to support.

Customer success doesn't evangelize product features and the customer doesn't know what new is coming unless they ask about it.