Datadog Reviews

Observability is a key use case, as is security.

With this product, we get more visibility into our K8s clusters and more intelligent alerting.

Datadog dashboards are pretty great.

We need more integration with security tools like Drata.

I've used the solution for three years.

The main use case is observability and reliability as part of a platform/delivery engineering solution. We use the product to assist tenants and clients within the company to get more ramped up on SRE/DevOps.

The solution has provided us with a lot more insight into service-level metrics, which is especially useful with APM/tracing. It gives us all-up dashboards and alerts to assist with incident management.

The most useful aspects of the product are the dashboards and APM/tracing. The tools are powerful and intuitive to set up as well.

Custom-level metrics could be improved.

Billing should be more transparent.

I've used the solution for three to four years at multiple companies.

The solution is very stable.

The scalability is fantastic so far.

Technical support has been great so far.

The initial setup is straightforward. The documentation we use is very clean and concise.

We handled the initial setup in-house.

I would advise others to be cautious around custom metrics and be picky when setting them up.

We primarily use the product for tracing, metrics, and alarms in various deployment environments.

The product has provided our company with improved observability, which has helped make the incident response more targeted and quicker.

APM is great and has provided low-effort out-of-the-box observability for various services. 

Monitors are helpful, and definitions are simple. 

Terraform support is nice as it allows us to create homogenous monitoring environments in various deployment environments with little additional effort. It also facilitates version control of monitor definitions, etc. 

The Golang profiler is generally good with the exception of delta profiles; it has provided helpful observability into Heap Allocations which has helped us reduce GC overhead.

Delta traces on the Golang profiler are extremely expensive concerning memory utilization. In a Kubernetes environment where we would like to set per-pod memory allocations as low as possible, the overhead of that profiler feature is prohibitive. In one case, our pods (which were provisioned to target 250 MB and max at 500 MB memory) got stuck in a crash loop due to out-of-memory, which was caused entirely by the delta profiles feature of the profiler.

Multistep Datadog synthetics lack the feature of basic arithmetic. For our use case, performing basic arithmetic on the output of previous steps to produce input for subsequent steps would be extremely useful.

I've used the solution for nine months.

We are providing managed services to our customers across multiple industries. Datadog is key to delivering these services by bringing the observability, monitoring, and alerting capabilities we need to operate at scale. 

We operate custom cloud native workloads as well as ISV products such as Atlassian Jira or Confluence. 

Integrating Synthetics, infrastructure, and application performance monitoring, as well as piping all logs through Datadog allows us to operate more with less with good alerting right in time.

We are providing managed services to our customers across multiple industries. 

Datadog is key to delivering these services. It brings in observability, monitoring, and alerting capabilities - all of which we need to operate at scale. 

We operate custom cloud native workloads as well as ISV products such as Atlassian Jira or Confluence. 

Integrating Synthetics, infrastructure, and application performance monitoring, as well as piping all logs through Datadog, help with getting alerts in real-time.

We are providing managed services to our customers across multiple industries. 

Datadog delivers observability, monitoring, and alerting capabilities we need to operate at scale. 

Operating custom cloud native workloads as well as ISV products such as Atlassian Jira or Confluence is also something we do. Integrating Synthetics, infrastructure, and application performance monitoring, as well as piping all logs through Datadog allows us to operate while grabbing alerts in real-time.

The current way accounts are billed could be vastly improved - especially when involving multiple organizations across multiple accounts in combination with reserved commitments. 

Being able to have an automatic materialized report on certain dashboards that could be exported as PDF to be shared with non-Datadog users could help a lot. 

Other than that, we are more than happy with the features we use regularly.

We have been using Datadog since 2015.

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.

I am using the solution for monitoring metrics, logs, traces, etc. It's mainly for making dashboards as well as monitoring our services. 

We also use Datadog to help centralize our incident management to show the logs, where issues spiked, and some metrics. 

We use Datadog to do troubleshooting in Kubernetes, specifically in our Azure Kubernetes service. Beyond that, we are looking to use open telemetry in tandem with Datadog to further our log-tracing efforts. In the future, this may be expanded.

This solution improves our organization as now we have higher visibility into our application that we otherwise would not have. 

Since the Datadog agent comes in three forms, agentless, scraping, and through the API, it is very flexible. It is this flexibility in how to report our logs that keeps our logs centralized and organized. 

One major drawback of Datadog is the cost. Sometimes we set up flows in place to monitor resources that end up logging more than we thought, and the bill is too high.

Dashboards have been marrying the most valuable parts of Datadog. Dashboards use metrics that are very helpful for monitoring services. I recently used metrics to monitor the number of pods in Kubernetes, the spikes in requests in Kubernetes, and overall CPU and memory usage in our Kubernetes clusters. 

We can also use log analytics to further our understanding. We can handle debugging and find out why things are breaking in our applications. 

The log portion of Datadog has robust features to debug the applications we are running. I really appreciate the ability to use facets to par down the logs.

The documentation leaves a lot to be desired for new users. The documentation is way too much text and has no real information just to help get people started. Sometimes it doesn't help to read an entire essay just to get a grasp on how the logs or metrics work.

I've used the solution for two years.

We use the solution for testing all of our application's endpoints. It is making sure that they work on a consistent basis.

We enjoy the multistep API tests.

They need to implement template variables into the message response body. They could be injected in the subsequent calls. However, they fail to be able to use those variables anywhere in the alert body message that is sent out.

We've been using the solution for a year.

I've never thought about stability and have no insights.

I find we are getting tossed from engineer to engineer. It is not fun when you have an ongoing problem. That is something from the customer resolution team that needs to be addressed.

Positive

We previously used Selenium. I was forced to use it. However, Datadog was a way simpler solution to setting up browser and API tests quickly.

The solution is very straightforward since it has a good GUI.

The initial setup was handled in-house.

It is not my job to track the ROI.

I have no details about the pricing. 

We did not evaluate other solutions. 

The solution is a SaaS.

We use this solution to monitor our Kubernetes clusters, nodes, deployments, daemon sets, replica sets, and pods.

I've been using this solution for a few months at my current company as a member of the Kubernetes team we use Datadog to provide monitoring and telemetry for our team and our customers.

This solution has improved our organization by giving us deeper insight into what's running in our clusters and their performance of it.

I have found the logging and tracing features the most valuable.

The documentation could be improved regarding setting up the agent properly and debugging.

I've been using this solution for a few months at my current company.

Our use case is mainly deploying into our applications for monitoring/logging observability. We currently have our microservices feed into an actuator that exists in each instance of our application that extends to a local and central Grafana for client and internal visibility. The application we use is Grafana.

Logging captures application and system logs that are ported to each application instance for querying.

Whenever anything occurs that is considered unhealthy from a range of health checks, we have notification rules configured internally and externally for a prompt response time.

We have been able to be a more confident, knowledgeable, and capable team when everything is being ported into a centralized format. Beforehand, knowledge was isolated to individuals. Knowledge in terms of what information represented and where it was led to a lack of confidence. By having everything in one place, rules out that confusion and allows us to respond better to issues.

It also allows for personal growth as our team is learning the application from the ground up, and each person is enhancing their own skills.

The valuable features include the following: 

• We are currently utilizing a decentralized distributed framework for our deployment, including our monitoring/logging observability capabilities. Centralizing them, if contingent on our company privacy guidelines, will be a big help in tracking and responding to issues that come up and have the means to understand the origin of the log management tools that were demonstrated.
• The ability to fiddle around and manipulate how logs are outputted.
• The ability to track AWS Lambda functions, Cloudformation, and Cloudwatch allow someone that is not savvy to dip their toe into understanding their own product.
• The integration into AWS is key as well as our software is currently bound to AWS.

The ability to find what you are looking for when starting out could be improved. It was a bit overwhelming trying to figure out what is the best solution. It led to many prototypes or time spent just perusing documentation. If we were able to select bundles or template use cases, we would hit the ground running quicker.

I've used the solution for one year.

We primarily use the solution for monitoring applications and informing customers via Pagerduty and Statuspage. The monitoring and alerts can be personalized internally, and we are able to find problems and issues. The response time monitor has been great, and it has been validating upgrades. We can check in to see which step fails,

Previously, we had monitors scattered with different places and products, making troubleshooting harder and slower. Also, logs and monitors were on different platforms, making it harder to put the infrastructure puzzle together.

Datadog documentation on web pages has improved a lot and is pretty easy to follow and find.

Additionally, integrations with, for example, GCP, Network, component, and Software providers are much easier as everything is now centralized.

API and notification integrations are also a great benefit for our organization.

Datadog is listening actively for customer feedback and develops improvements for us effectively.

The most valuable features of the solution include the APM, log monitor, SQL monitors, network monitors, and integrations.

Alerting timing should be improved to be more fine-tuned and exact. The current problem is that monitoring is integrated with the Statuspage and the SLA.

Also, browser support for browsers other than Chrome should be added. Browser test recording is another problem, as it does not always work in normal mode. One needs to use incognito mode or a pop-up.

I've been using the solution for three years.