Datadog Reviews

We use the product for recording loggers on our various services across different teams. For example, we use logs to keep track of info logs for events and error logs to catch exceptions. 

When users ask us to investigate a situation, we use logs to keep track of events and where the user's code traveled to. We also use synthetic testing and monitoring features to keep track of our many alerts in the production and QA environments.

We use Datadog mainly for debugging purposes. For example, we use it to navigate where the code trace is when an issue arises due to its ability to search through the logs. 

We also use it to address user queries. Sometimes users would ask us a certain question concerning our codebase, we use Datadog to track the code stack and also use time monitoring to get an idea of the time frame around when the use case happened.

The feature I have found to be the most valuable is the filtering feature in logs. It is really easy to type plus and minus to filter out different logs. I use it to navigate the noise. 

I use synthetic tests as well. It is easy to navigate the menu and create tests. 

Much of the UI is very straightforward, and I do appreciate the ability to search for any documentation on the various features when I need to as well. The DASH monitoring boards are nice to give an overview of various performances and allow us to track use cases.

This service could be less costly. Right now, we only keep 15 days worth of logs since we want to be more economical in terms of cost. It would be nice if I had the option to monitor logs beyond 15 days. For APM traces, we only keep a year worth of traces. The UI can be a little more straightforward as well. I found it to have too many options.

I've used the solution for three years.

The stability is good.

The scalability is good.

We deploy various services for our main platform on AWS across multiple regions. We have a development environment, a staging environment, a QA environment, and a production environment. We deploy our many services across hundreds of instances. 

We have many server farms, all responsible for various services on our market intelligence platform. The deployment of each server farm or even individual instances varies depending on what stood up. We have instances built in three different ways, with two different pipelines and some even on user data scripts.

My team has a 24/7 on-call schedule where we need to be ready to handle and mitigate incidents with the platform at any moment. 

We have countless monitors set up on Datadog that alert directly to our queue using an email that generates a ticket. 

The actionable steps for each type of monitor and its associated incident are easily included in the alerts whenever something is triggered. We generate links to the Datadog monitors and can instantly drill down into what went wrong and for how long.

The features I have found most helpful are synthetic monitoring, APM, and alert features. The monitoring functionality, in general, and tagging infrastructure are great.

Synthetics have become bread and butter for us as we have migrated many tests over to Datadog. We have simplified and consolidated our synthetic tests while also making them more robust with the help of your tagging. 

A large portion of our monitoring is based on synthetics results, and alerts integrate seamlessly without an incident queue system. We use dashboards heavily. 

The metrics capabilities are extremely helpful, and we use virtually all of the widgets.

My main place of improvement for Datadog would be the documentation. While the tool is robust with many different capabilities, users would greatly benefit from more examples in the documentation. 

The number of current code snippets available in the docs is not enough, and some need to be updated even today. 

One function I would add would be a button to generate a report of the performance of a synthetic test and the performance of each of the steps in the test over time.

This timeline varies in terms of how long we've used the solution. We have one platform completely in the cloud and one still on-premises. We've had the solution for many years on AWS.

We currently use it for log aggregation and SEIM. We send logs from our AWS account (particularly our Cloudtrail and S3 logs) and use them to give us security signals. 

This has helped with our SOC2 certification process and has given us a window into our processes and the security holes in our system. 

We are also considering using the APM features to help with our development effort. We want to be able to profile all of our code and see what is going on with it.

It has allowed us to see into our systems with ease. We are a very small startup (Less than 30 people, and most of them are in sales and marketing). 

When it comes to managing systems, we just don't have time to do everything. However, Datadog has allowed us to do much more with fewer people and still sift through our data with ease. 

We hope to start using the APM feature set to extend this to our dev teams as well.

The ease of use is the primary aspect. I have used, at previous jobs, the ELK stack and Splunk for log management. Both of them were useful, yet required a lot of manual effort to get set up (and a lot of continuing effort to tweak. A simple monitoring solution turned into a full-time job! However, Datadog has so far been a breeze to use and set up. It looks at what I am sending it and figures out what it is almost by magic. Even the manual configuration makes sense and gives very fast and thorough results

One thing we have run into is that it is so easy to add monitoring that we turn on things without really understanding the costs. 

I would like a way to show a continuous indication of what my setup will cost on a daily or weekly basis.

I've used the solution for six months.

We use Datadog to view and aggregate logs and monitor all of our services. We have a lot of running infrastructure and it is very convenient to have logs and metrics all aggregated somewhere we can view and chart them. 

I use Datadog to create dashboards and runbooks, and sharable graphs, which really help out my whole team. We mostly use logs and APM, yet have been starting to use other products. I would like to use more synthetic monitors.

It has democratized our logs and metrics, allowing all engineers to have insight into how our apps perform. It is also extremely helpful when debugging issues. 

It would be very difficult to debug issues without aggregated logs and APM traces. 

It has also definitely saved us some money since we can keep an eye on our running infrastructure in an easy-to-see way, rather than a less friendly CLI. It has been a very big help!

The log stream has been the most useful thing. Having so many logs on so many different running containers means it is very inconvenient to view them individually. Datadog's log aggregation is really helpful since it lets me and every other engineer on my team login, view, and share logs when we need to debug our application. 

APM has also been extremely helpful for debugging issues and profiling and optimizing our apps. Dashboards have also been really helpful for communicating needs and priorities to engineering leadership. 

It is very easy to get buy-in with graphs to back things up.

I recently saw the education, and it is amazing. Events like DASH are extremely helpful in understanding the deep set of features. Anything that helps to educate users is a huge win here. 

The menu on the left is pretty dense (and I know it has to be). I never knew about the cmd+k functionality until recently. It would be helpful to offer more tips/cheat sheets to see handy shortcuts like that.

I've used the solution for three years. 

We previously used AWS Cloudwatch logs. It was way less friendly and fully featured.

The solution is pretty straightforward to set up. It helps with logs and metrics, and the AWS integration is really great.

We handled the implementation in-house.

It is hard to educate an entire team. There is a big learning curve.

We use an enterprise version of a CMS platform which is enabling businesses to transmit content to their customers. The tool is fully customizable to the end user, including out-of-the-box integrations as well as APIs for custom plugin support. 

Our systems fully manage content using AWS as the back-end cloud provider. Assets are kept in secure buckets and utilize the Kubernetes infrastructure to deliver our product to end users and internal authors. Using the CMS allows for business people to manage content without needing development efforts.

This tool is the sole purpose of my company and the solutions we provide around it. Enabling customers to manage their content in a fast, reliable, and highly user-friendly setup has been critical to our success. 

Offering our product at SaaS, PaaS, cloud, and on-prem editions has enabled us to provide a solution for all types of customers. 

The platform appeals to companies spanning many industries on a global scale. 

Being based in SUI allows us to secure both the EU and other companies more easily.

The enterprise version of a CMS platform enables businesses to transmit content to their customers. 

The tool is fully customizable to the end user, including out-of-the-box integrations as well as APIs for custom plugin support. 

The content is fully managed within our systems using AWS as the back-end cloud provider. Assets are kept in secure buckets, and we can utilize the Kubernetes infrastructure to deliver our product to end users and internal authors. 

Using the CMS allows for business people to manage content without needing development efforts. Allowing this type of setup for business users has been a key reason for our success.

There is always room for improvement when dealing with cloud-based technologies. Mainly, I would say, it's just increasing our offerings to attract various other types of industries and businesses across more fields. 

New features as requested by our existing customers will help make the product better.

The product was self-developed.

We use a SaaS deployment. 

We use the solution primarily for platform monitoring for the services that are deployed in AWS. It gives a better way to monitor the services, including pods, cost, high availability, etc. This way, observability is ensured and also customer services are uninterrupted. 

Also, we host the data pipelines between the cloud and the on-prem for which Datadog is used to ensure better services. We report issues based on the metrics reported over it. 

Cost and performance optimization were the major enhancements for our organization. It gives us platform monitoring for the services that are deployed in AWS for a better way to monitor the services (pods, cost, high availability, etc.). With this product, we ensure that observability and also keep customer services uninterrupted. We host the data pipelines between the cloud and the on-prem. Datadog helps to ensure better services. We find we can report issues based on the metrics reported over it.

The observability pipelines are the most valuable aspect of the solution. 

Platform monitoring for the services that are deployed in AWS is helpful. It gives a better way to monitor the services. With Datadog, we ensure observability and maintain uninterrupted customer service. 

We can host the data pipelines between the cloud and the on-prem. Issues are easily reported.

The data streams are good. Data lineage is something that really helped in ensuring tracking of the data and metrics and also the volumes processed.

We'd like to see better transformers.

Live chat would be the best way to support us. 

Also, the features that we saw getting launched recently were something we expected and we're glad to see them coming.  

Geo-data is also something very critical that we hope to see in the future.

I've used the solution for two or more years. 

We use Datadog for three main use cases, including:

• Infrastructure and application monitoring. It is ensuring that our services are available and performant at all times. This allows us to proactively address incidents and outages without customers contacting us. This includes monitoring of cloud resources (databases, load balancers, CPU usage, etc.), high-level application monitoring (response times, failure rates, etc.), and low-level application monitoring (business-oriented metrics and functional exceptions to customer experience.
• Analyzing application behavior, especially around performance. We often use Datadog's application performance monitoring on non-production environments to evaluate the impact of newly introduced features and gain confidence in changes.
• End-to-end regression testing for APIs and browser-based experiences. Using Datadog's synthetic testing checks periodically that the system behaves in the exact correct way. This is often used as a canary to detect issues even before users reach them organically.

Since we integrated Datadog, we have had increased confidence in the quality of our service, and we had an easier time increasing our delivery velocity. 

We have seen time after time that the monitors we have carefully created based on all ingested data are detecting issues quickly and accurately. 

This means we allow ourselves to manually test things less frequently. We have also had an easier time investigating application errors and slowness using Datadog's APM and log explorer products which allow us to introspect any part of the system, in its execution context.

The most valuable features include:

• Integrated observability data ingestions: All data that Datadog collects is connected. This allows easily connected logs with failed requests, and slow database questions with services and requests.
• Broad integrations allow us to monitor our entire production environment in a single place, not just cloud resources. Since all parts stream metrics, logs, and events to Datadog, we can have unified dashboards and manage monitors and incidents all from the same page.
• A high level of configuration. We can configure and modify many parts, from how data is collected from our applications to how Datadog parses and visualizes it. This means that we always get the best experience, and we don't need to find ten different products that do small things well or settle on one product that does everything badly.

Since the Datadog platform has so many separate features, solving so many use cases, there are often inconsistencies in feature availability and interoperability between products. 

Older, more mature products tend to be complete (many features, customization, broad integrations, etc.), while newer products will often be at a "just above minimum viable product" phase for a long time, doing what's intended yet missing valuable customizations and integrations.

We've used the solution for 12 months.

The solution scales very well on technical aspects, being able to ingest large quantities of data from many services. However, the pricing often doesn't scale naturally, and effort has to be put in to keep ongoing costs at a reasonable amount.

Customer service and support are generally very high-quality. In most cases, they reply very quickly and offer well-researched and relevant responses. This is contrasted with many vendors who take a long time to reply and send links to documentation instead of understanding the problem.

However, we had cases where support took several weeks to reply to a complicated request and sometimes eventually responded that the issue cannot be resolved. These are rare edge-case occurrences.

Positive

A large part of the initial setup was straightforward. We were able to collect about 80% of the relevant and 90% of the meaningful insights from just a couple of hours of connecting the AWS integration and the Datadog APM agent. 

Getting it to 100% and configuring and customizing things to our unique situation, took about two weeks. Datadog's documentation and support team were extremely helpful during both phases.

We handled the setup in-house.

From the number of outages stopped or shortened (which lead to lost revenue from non-renewals) and the number of hours saved on investigations (which correlates to engineering salaries), I estimate that the ROI of the implementation time and monthly charges to be between 10x and 20x.

We use the solution as a SaaS deployment.

We primarily use the solution for log management and application performance monitoring. We have been getting into using more solutions on Datadog, such as runbooks, monitoring, and dashboards. 

Another area that we've been investing some time in is the database monitoring. We've been able to get some relatively new employees onboarded into the tool, and they've been able to create some meaningful dashboards and reports without too much hand-holding at all. 

We plan on exploring the synthetics solution as well.

We are still working through fully rolling the service out to our employees. Those that have so far begun using it have found that it decreases the time required to investigate and troubleshoot production issues. 

We have found that we're able to get in and out of troubleshooting issues much more rapidly, which in turn, of course, enables us to spend more time on our products. We are still investigating other areas where other Datadog services could potentially be injected into our workflows.

Correlation between logs and APM has been the most important feature that we've found in Datadog to date. Previous solutions around log collection or APM instrumentation were rather cumbersome to connect. We previously needed to use different solutions for each which were not connected and required complex queries and a lot of time investment by key employees.

The search and filtering capabilities are rather helpful as well. The aggregation of all currently available properties has been great. It's excellent that available options drop as filters are refined. This allows for a nuanced view of available data.

We intend on exploring other products at Datadog, so this list may expand.

I've found that the documentation is lacking in certain regards. In going through sessions around certain services, the presenter expressed opinions on best practices that are not covered by documented examples. 

In taking these thoughts to the "experts," further research is required both by us and those working the table to come to a solution that meets our needs. If there were more documentation on best practices this may be easier to manage.

I've been using the solution for ten years. 

The solution overall seems rather stable.

The solution seems scalable. We just need to keep an eye on the costs as it scales.

Customer support has been ok, yet not great. We've had ticket resolution drag on for weeks.

Neutral

We previously used Scalyr for logs and switched due to APM linkage.

The initial setup was straightforward.

We handled hte setup in-house.

We've saved many developer hours by using Datadog. We plan on expanding our investment in this solution (and thus our return).

Pricing can be a bit of a sell internally. We've found it to be worth it, though.

We came from using other solutions.

We are trying to get a handle on observability. Currently, the overall health of the stack is very anecdotal. Users are reporting issues, and Kubernetes pods are going down. We need to be more scientific and be able to catch problems early and fix them faster.

Given the fact that we are a new company, our user base is relatively small, yet growing very fast. We need to predict usage growth better and identify problem implementations that could cause a bottleneck. Our relatively small size has allowed us to be somewhat complacent with performance monitoring. However, we need to have that visibility.

We are still taking baby steps with Datadog. Hence, it's hard to come up with quantifiable information. The most immediate benefit is aggregating performance metrics together with log information. Having a better understanding of observability will help my team focus on the business problems they are trying solve and write code that is conducive to being monitored, instead of reinventing the wheel and relying on their own logic to produce metrics that are out of context

The most useful feature is the APM. Being able to quickly view which requests are time-consuming, and which calls have failed is invaluable. Being able to click on a UI and be pointed to the exact source of the problem is like magic. 

I'm also very intrigued by log management, although I haven't had quite a chance to use it very effectively. In particular, the trace and span IDs don't quite seem to work for me. However, I'm very keen on getting this to work. This will also help my developers to be more diligent and considerate when creating log data.

As a new customer, the Datadog user interface is a bit daunting. It gets easier once one has had a chance to get acquainted with it, yet at first, it is somewhat overwhelming. Maybe having a "lite" interface with basic features would make it easier to climb the learning curve.

Maybe the feature already exists. However, I'm not sure how to keep dashboard designs and synthetic tests in source control. For example, we may replace a UI feature, and rebuild a test accordingly in a pre-production environment, yet once the code is promoted to production, the updated test would also need to be promoted.

We have just started using the solution and have only used it for about two months.

We're new at this. That said, so far, there haven't been any issues to report.

I have not had the opportunity to evaluate the scalability.

Customer support is full of great folks! We're beginning our Datadog journey, so I haven't had that much experience. The little I have had has been great.

Positive

This is all new. 

We used to work with New Relic. New Relic has an amazing APM solution. However, it also became cost-prohibitive

Since we are relatively greenfield, it was relatively painless to set up the product. 

Our in-house DevOps team did the implementation.

I don't know what the ROI is at this stage.

I'm not sure what the exact pricing is. 

So far, it's been great!

We use the solution primarily for distributed tracing, service insight and observability, metrics, and monitoring. We create custom metrics from outbound service calls to trace the availability of back-office systems. 

We use the flame graph to get insights into our GraphQL implementation. It helps highlight how resolvers work. 

However, it's lacking in tracing which GraphQL queries are run, and we use custom spans for that.

Prior, the team only had Instana, and few people used it. The main barriers to entry were the access (since it was not integrated into our SSO) and the user experience, which made it hard to follow. We had an on-prem version, and it wasn't the snappiest. The APM has made observability and tracing more accessible to developers.

Flame graphs are pretty useful for understanding how GraphQL resolves our federated queries when it comes to identifying slow points in our requests. In our microservice environment with 170 services. There are complex transactions over the course of a single user request since we essentially operate as a middle layer with 90 back office systems we integrate to.

I often have issues with the UI in my browser. I tend to have a lot of tabs open, yet have issues with it not responding or not showing data. A couple of times, pasting the URL into an incognito window shows the data that's there.

I've used the solution for two years. 

The initial setup was complex and required a bit of tweaking to get everything configured correctly and into our pipelines.