Datadog Reviews

We use the solution for monitoring microservices in a complex AWS-based cloud service.  

The system is comprised of about a dozen services. This involves processing real-time data from tens of thousands of internet connected devices that are providing telemetry. Thousands of user interactions are processed along with real-time reporting of device date over transaction intervals that can last for hours or even days. The need to view and filter data over periods of several months is not uncommon.  

Datadog is used for daily monitoring and R&D research as well as during incident response.

The query filtering and improved search abilities offered by Datadog are by far superior to other solutions we were using, such as AWS CloudWatch. We find that we can simply get at the data we need quicker and easier than before. This has made responding to incidents or investigating issues a much more productive endeavour. We simply have less roadblocks in the way when we need to "get at the data". It is also used occasionally to extract data while researching requirements for new features.

Datadog dashboards are used to provide a holistic view of the system across many services. Customizable views as well as the ability to "dive in" when we see someting anomalous has improved the workflow for handling incidents.    

Log filtering, pattern detection and grouping, and extracting values from logs for plotting on graphs all help to improve our ability to visualize what is going on in the system. The custom facets allow us to tailor the solution to fit our specific needs.

There are some areas on log filtering screens where the user interface can take some getting used to. Perhaps having the option for a simple vs advanced user interface would be helpful in making new or less experienced users comfortable with making their own custom queries.

Maybe it is just how our system is configured, yet finding the valid values for a key/value pair is not always intuitively obvious to me. While there is a pop-up window with historical or previously used values and saved views from previous query runs, I don't see a simple list or enumeration of the set of valid values for keys that have such a restriction.

I've used the solution for one year.

The solution is very stable.

The product is reasonably scalable, although costs can get out of hand if you aren't careful.

I have not had the need to contact support.

Neutral

We did use AWS CloudWatch. It was to awkward to use effectively and simply didn't have the features.

We had someone experienced do the initial setup.  However, with a little training, it wasn't too bad for the rest of us.

We handled the setup in-house.

Take care of how you extract custom values from logs. You can do things without thought to make your life easier and not realize how expensive it can be from where you started.

I'm not aware of evaluating other solutions.

Overall I recommend the solution. Just be mindful of costs.

Our primary use case is custom and vendor-supplied web application log aggregation, performance tracing and alerting. 

We run a mix of AWS EC2, Azure serverless, and colocated VMWare servers to support higher education web applications. 

We're managing a hybrid multi-cloud solution across hundreds of applications, which is always a challenge. There are Datadog agents on each web host, and native integrations with GitHub, AWS, and Azure and that gets all of our instrumentation and error data in one place for easy analysis and monitoring.

Through the use of Datadog across all of our apps, we were able to consolidate a number of alerting and error-tracking apps, and Datadog ties them all together in cohesive dashboards. Whether the app is vendor-supplied or we built it ourselves, the depth of tracing, profiling, and hooking into logs is all obtainable and tunable. Both legacy .NET Framework and Windows Event Viewer and cutting-edge .NET Core with streaming logs all work. The breadth of coverage for any app type or situation is really incredible. It feels like there's nothing we can't monitor.

When it comes to Datadog, several features have proven particularly valuable. 

The centralized pipeline tracking and error logging provide a comprehensive view of our development and deployment processes, making it much easier to identify and resolve issues quickly. 

Synthetic testing has been a game-changer, allowing us to catch potential problems before they impact real users. Real user monitoring gives us invaluable insights into actual user experiences, helping us prioritize improvements where they matter most. And the ability to create custom dashboards has been incredibly useful, allowing us to visualize key metrics and KPIs in a way that makes sense for different teams and stakeholders. 

Together, these features form a powerful toolkit that helps us maintain high performance and reliability across our applications and infrastructure, ultimately leading to better user satisfaction and more efficient operations.

I'd like to see an expansion of the Android and IOS apps to have a simplified CI/CD pipeline history view. 

I like the idea of monitoring on the go, however, it seems the options are still a bit limited out of the box. While the documentation is very good considering all the frameworks and technology Datadog covers, there are areas - specifically .NET Profiling and Tracing of IIS-hosted apps - that need a lot of focus to pick up on the key details needed. 

Sometimes, the screenshots don't match the text as updates are made. I spent longer than I should have figured out how to correlate logs to traces, mostly related to environmental variables.

I've used the solution for about three years.

We have been impressed with the uptime and clean and light resource usage of the agents.

The product is very scalable and very customizable.

Technical support is always helpful to help us tune our committed costs and alert us when we start spending out of the on-demand budget.

We used a mix of a custom error email system, SolarWinds, UptimeRobot, and GitHub actions. We switched to find one platform that could give deep app visibility regardless of Linux or Windows or Container, cloud or on-prem hosted.

The setup is generally simple. .NET Profiling of IIS and aligning logs to traces and profiles was a challenge.

We implemented the solution in-house. 

ROI is reflected in in significant time saved by the development team assessing bugs and performance issues.

Set up live trials to asses cost scaling. Small decisions around how monitors are used can impact cost scaling. 

NewRelic was considered. LogicMonitor was chosen over Datadog for our network and campus server management use cases.

We're excited to explore the new offerings around LLM further and continue to expand our presence in Datadog. 

We are using a mixture of on-prem and cloud solutions to bridge the gap with healthcare entities in the service of providing patients with the medication they need to live healthy lives.

Since we're a heavily regulated company, a lot of our solutions grew from on-premises monoliths. However, as we scaled out, it became harder and harder to move forward with that architecture. Today, we're investing heavily in transforming our systems from monoliths into distributed systems.

With this change in mind, the ability for us to connect the dots using Datadog has been invaluable.

We have an API that serves as a critical aspect of our system for generating new requests for us to process in service of a patient. This service has many tentacles, and it was always hard to track down how issues from this API are affecting things downstream. Since we've added more instrumentation in this API, Datadog has changed our status from a reactive posture to a proactive one.

It has also served as a prime example to other applications on what the benefit of a well-instrumented system is for that application and other applications around it. Due to this, more and more people are using Datadog.

We like the distributed tracing and flame graphs for debugging. This has been invaluable for us during periods of high traffic or red alert conditions. It has also informed our developers on how our various systems are interconnected and the downstream effects of the problems we might encounter for certain services.

We're still working on getting widespread adoption of these products. Still, we're already seeing a shift in the developer's perspective from application-specific and starting to look at things from a more holistic systems perspective.

While this is not part of the question, this is relevant: Now that I've learned more about RUM, this will be something that we will heavily leverage moving forward to give us a whole complete view of our system from the front and back end perspective.

Once Datadog has gained wide adoption, it can often be overwhelming to both know and understand where to go to find answers to questions. Currently, we use a combination of documentation and COPs to ensure that folks know how to leverage what we have in Datadog properly.

While the guides for Datadog go a long way, a way to customize the user experience from "advanced" to "novice" mode would go a long way.

I've been using the solution for two years.

It has never failed us and therefore I consider it to be very stable.

It's magic. For the most part, we just installed the product and a lot of it just worked out of the box.

Technical support is excellent.

Positive

We have used Splunk, Sentry, and a suite of hand-made solutions. We switched since the Datadog solution was both comprehensive and cohesive. It was also easier to onboard people since the solution was well-documented and standardized.

For the most part, it was really painless to set up.

We implemented the solution in-house.

We're still early on in our transformation process. That said, we are gaining a lot of steam in terms of adoption. Both the engineering team and the product team are seeing tremendous value from this solution.

Adding more tooltips and links to documentation or how-tos within the application would really go a long way for those trying to get their feet wet with Datadog.

I used Datadog typically for monitoring website statistics and some of the cloud networking equipment.

The most valuable features are the dashboards and the reporting.

I have been using this solution for approximately three years.

I found the solution to be stable, I did not experience any bugs or glitches. However, some of the managing team did.

The scalability of the solution was good. Being a cloud solution, if there was an issue with the scalability it would be easily fixed with an update.

We have approximately 200 users using the solution in my organization.

I did not need to use the support.

I was previously using SolarWinds in the company I was working with before.

I rate Datadog nine out of ten.

In our fast-paced environment, managing and analyzing log data and performance metrics is crucial. That’s where Datadog comes in. We rely on it not just for monitoring but for deeper insights into our systems, and here’s how we make the most of it. 

One of the first things we appreciate about Datadog is its ability to centralize logs from various sources—think applications, servers, and cloud services. This means we can access everything from one dashboard, which saves us a lot of time and hassle. Instead of digging through multiple platforms, we have all our log data in one place, making it much easier to track events and troubleshoot issues.

Before Datadog, we faced the common challenge of fragmented data. Our logs, metrics, and traces were spread across different tools and platforms, making it difficult to get a complete picture of our system’s health. 

With Datadog, we now have a centralized monitoring solution that aggregates everything in one place. This has streamlined our workflow immensely. Whether it’s logs from our servers, metrics from our applications, or traces from user transactions, we can access all this information easily. This unified view has made it simpler for our teams to identify and troubleshoot issues quickly.

In my experience with Datadog, one feature stands out above the rest is the Log Explorer. It has completely transformed the way I interact with our log data and has become an essential part of my daily workflow. 

The user interface is incredibly intuitive. When I first started using it, I was amazed at how easy it was to navigate. The design is clean and straightforward, allowing me to focus on the data rather than getting lost in complicated menus. Whether I’m searching for specific log entries or filtering by certain criteria, everything feels seamless. 

This ease of use allowed me to get up to speed with log management since it's my first time using Datadog.

Interactive tutorials could be a game changer. Instead of just reading about how to use query filters, users could engage with step-by-step guides that walk them through the process. For example, a tutorial could start with a simple query and gradually introduce more complex filtering techniques, allowing users to practice along the way. These tutorials could include pop-up tips and hints that provide additional context or best practices as users work through examples. This hands-on approach not only reinforces learning but also builds confidence in using the tool.

My company has recently made Datadog available to it's software engineers and I personally have been using it for almost a year now.

We use the product for instrumentation, observability, monitoring, and alerting of our system. 

We have multiple environments and a variety of pieces of infrastructure including servers, databases, load balancers, cache, etc. and we need to be able to monitor all of these pieces, while also retaining visibility into how the various pieces interact with each other. 

Tracing data between components and user interactions that trigger these data flows is particularly important for understanding where problems arise and how to resolve them quickly.

It provides a lot of options for integrations and tooling to observe what is happening within the system, making diagnosis and triage easier/faster. 

Each user can set up their own dashboards and share them with other users on the team. We can instrument monitors based on various patterns that we care about, then notify us when an event triggers an alert with platforms such as Slack or PagerDuty. 

Our ability to rapidly become aware of problems focused on the symptoms being observed and entry points into the tool to rapidly identify where to investigate further is important for our team and our users.

The most valuable aspects of the solution include log search to help triage specific problems that we get notified about (whether by alerts we have configured or users that have contacted us), APM traces (to view how user interactions trace through the various layers of our infrastructure and services to be able to reproduce and identify the source of problems), general performance/system dashboards (to regularly monitor for stability or deviation), and alerting (to be automatically informed when a problem occurs). We also use the incident tools for tracking production incidents.

In some ways, the tool has a pretty steep learning curve. Discovering the various capabilities available, then learning how to utilize them for particular use cases can be challenging. Thankfully, there is a good amount of documentation with some good examples (more are always welcome), and support is very helpful. 

While DataDog has started adding more correlation mapping between services and parts of our system, it is still tricky to understand what is the ultimate root cause when multiple views/components spike. Additionally, there are lots of views and insights that are available but hard to find or discover. Some of the best ways to discover is to just click around a lot and get familiar with views that are useful, but that takes time and isn't ideal when in the middle of fighting a fire.

I've used the solution for about four years.

It seems stable.

It seems to scale well. Performance for aggregating or searching is usually very fast.

Technical support is helpful and pretty responsive.

Positive

We did not use a different solution. 

It's hard to say what ROI would be as I have not managed our system without it to compare to.

I don't manage licensing.

We did not evaluate other options. 

It's a great tool with new features and improvements continuously being added. It is not simple to use or set up, however, if you have the right personnel, you can get a lot of value from what DataDog has to offer.

Internally our primary usage of Datadog pertains around APM/tracing, logging, RUM (real user monitoring), synthetic testing of service/application health and state, overall general monitoring + observability, and custom dashboards for aggregate observability. We also are more frequently leveraging the more recent service catalog feature.

We have several microservices, several databases, and a few web applications (both external and internal facing), and all of these within our systems are contained within several environments ranging from dev, sit, eat, and production.

Datadog has had a massive impact on our department. Before, we had loose logging dumped into a sea of GCP logs with haphazard custom solutions for traceability between logs and network calls. Datadog has helped standardize and normalize our processes around observability while providing fantastic tools for aggregating insight around what is monitored regularly, all wrapped in an easy-to-use UI.

Additionally, a range of types of users exist within our department, each with its own positive impact on Datadog. DevOps leverages it to easily manage infra, developers leverage it to easily monitor/debug services and applications, and business leverages it for statistics.

Personally I've found the RUM (real user monitoring) to be above and beyond what I've worked with before. Client-side monitoring has always been on the short end of the stick but the information collected and ease of instrumentation provided by Datadog is second to none.

Having a live dynamic service map is also one of my favourite features; it provides real-time insights into which services/applications are connected to which.

We are also investigating the new API catalog feature set, which I believe will provide a high-value impact for real-time documentation and information about all of our shared microservices that other dev teams can use.

In production, we intend to use trace IDs generated by RUM to attach to support tickets when a user experiences a traceable network error, and we want to display this trace ID to the user so if they were to contact us about a specific issue, they can provide us an exact ID displayed to them back to us. Currently, this is not possible out-of-the-box client-side without inventing our own solution for capturing these trace IDs, such as shimming the native fetch or returning the ID from the service response.

I've used the solution for approximately two years across our department and around a year or so of it being used practically and fully integrated into our systems.

Aside from one very brief bad update from the Datadog team around RUM where they broke the native 'fetch' for node in an update to RUM (which was resolved quickly) as it used to -- and may still -- modified the global 'fetch'; Datadog as a whole solution has been highly stable.

It's easy to implement and scale provided a there's a solid IaC solution in place to integrate across your system.

The Datadog support team is prompt and helpful when tickets have been submitted from our end. When their support team have been unsure, they've properly reached out internally to the relevant SME to help answer any questions we've had prior.

Positive

I've personally dabbled with some other open-source observability and monitoring solutions; however, prior to Datadog, our department did not have any solutions other than log dumps to GCP.

The initial setup was straightforward from my own experience, helping integrate within the application and service levels; however, our DevOps team handled most of the infra process with minimal complaints.

We handled the solution in-house.

I personally am not involved in the decision around costing; however, I am aware that when we first set up Datadog, we explicitly configured our services/applications to have a master switch to enable Datadog integration so that we can dynamically enable/disable targeted environments as need due to the costs being associated on a per service basis for APM/logging/etc.

I was not involved in the decision-making regarding the evaluation of other options.

I highly recommend Datadog, and I would explore it for my own individual projects in the future, provided the cost is within reason. Otherwise, I would highly recommend it for any medium-to-large-sized org.

We use Datadog as our main monitoring platform across all environments, including production, staging, and development. 

It plays a crucial role in monitoring infrastructure performance, aggregating logs, and running synthetic and browser tests. Datadog helps us track critical system metrics like CPU, memory, and network traffic, allowing us to detect issues in real-time. 

Its log management and alerting features enable quick incident response, while synthetic monitoring ensures optimal user experience and service uptime by proactively identifying performance issues. We rely on browser tests to simulate real-world user interactions, ensuring that key workflows in our applications perform smoothly. 

Overall, Datadog allows us to maintain a high level of reliability and performance across our systems.

Datadog has significantly improved our ability to consolidate information into one central platform. Before implementing Datadog, our data and monitoring metrics were scattered across various systems and tools, making it difficult to get a unified view of our infrastructure and application health. This fragmented approach often led to inefficiencies, as we had to switch between different systems to gather relevant information, delaying our response to incidents. 

With Datadog, all our critical data—logs, metrics, and monitoring—is now integrated in one place, allowing us to easily correlate events, analyze performance, and quickly diagnose issues, greatly improving both operational efficiency and incident management.

The most valuable features we’ve found in Datadog are logging, API monitoring, infrastructure monitoring, and browser tests. 

Logging allows us to collect and centralize logs from across all our services, making it easier to troubleshoot issues and gain insights into application performance. 

API monitoring is crucial for ensuring the reliability and performance of our API endpoints, allowing us to detect issues proactively. 

Infrastructure monitoring gives us real-time visibility into our servers, containers, and cloud resources, helping us optimize performance and reduce downtime. 

Lastly, browser tests simulate real user interactions, ensuring that our web applications deliver a seamless experience by detecting any potential performance or functionality issues before they impact users. 

Together, these features provide a comprehensive monitoring solution, making Datadog an essential tool for maintaining system reliability and performance.

One area where Datadog could be improved is its pricing structure, which can sometimes make it cost-prohibitive to adopt new features. As we continue to scale, the costs associated with enabling more advanced monitoring capabilities, like additional integrations or more detailed data retention, can add up quickly. This makes it challenging for teams to justify the expense, especially when trying to utilize new features that could enhance monitoring and performance analysis.

Another improvement would be better cost transparency within the product’s GUI. Currently, it can be difficult to track how specific features or services are contributing to overall costs. If Datadog could provide more detailed, real-time insights into pricing directly within the interface—such as breakdowns of how much each feature or integration costs—it would help users manage budgets more effectively and avoid unexpected charges. A built-in budgeting tool or cost alerting system could also be useful, allowing organizations to make more informed decisions about what features to activate without the fear of overextending their budget.

Adding these features would give customers a clearer understanding of how to optimize their usage without overspending, making the platform even more accessible for teams that are cost-conscious but still want to take advantage of the full range of Datadog’s powerful capabilities.

I've used the solution for five years.

The solution is very stable.

It's very scalable. It can handle pretty much anything you throw at it.

Overall, support is very good and they have a responsive support team.

Positive

We previously had a range of open-source and in-house built tools. We switched to get everything in one place.

It was easy to understand and to implement. Datadog offers great documentation.

We implemented the solution in-house.

Beware of costs when using the platform. Set up alerting for unusual log volumes and set up rate limiting when possible.

We did evaluate logz.io.

It's a great product, although a bit expensive.