AWS CloudWatch vs Dashbird
Tags: aws, serverless, cloud, devops
Published: 2021-04-21 12:04:28

At this moment, billions of people are rushing to the internet for work, entertainment, shopping -- everything, really. It's great that we developed this virtual world and can keep the lights on, despite what's happening outside.

On the other hand, **cloud systems and developers are under pressure** to meet an **unparalleled demand**. At [Dashbird](https://dashbird.io/), we have always thought developers deserve the **most efficient tools** to **discover and resolve issues** in seconds in order to keep cloud apps running smoothly.

For applications running on AWS, CloudWatch might have been enough so far. In our research, though, we identified that teams **relying solely on CloudWatch** tend to **lag behind** on issue **discovery and resolution time**.

We have compiled this **feature comparison** list between AWS Cloudwatch vs Dashbird to help you decide on the most efficient tool for your specific needs.

AWS Cloudwatch monitoring
-------------------------

Don't get me wrong, Cloudwatch is not a bad tool by any stretch of the means. In fact, is pretty decent for keeping tabs on **what's going on in your AWS stack** if you take the **time to understand its intricacies**. It's the go-to tool for monitoring cloud resources in AWS and allows you to **track all your resources together**.

![AWS cloudwatch monitoring
](https://mk0dashbirdioprthk8x.kinstacdn.com/wp-content/uploads/2021/04/Screenshot-2021-04-21-at-11.46.08-1024x302.png)

One of the best features of Cloudwatch is the ability to **set up advanced alerts** that are, in my opinion, quite advanced. For example, you could set it up so that you'll get alerted when a particular functions use x amount of RAM or take more than x seconds to run. The alert will be **sent to your email **whenever the alert gets triggered.

My **main issue** with AWS Cloudwatch is probably **the way it displays information**. Running an actual application in the cloud can make it very difficult (I can't stress this enough) to **navigate the logs **especially when you have **multiple resources**. Since the **logs are all grouped together**, even though the information is all in there, **it takes A LOT of time and effort to get to the bottom of the problem**. Even reading the log itself can be tricky since it's just a long unformatted JSON string.

Dashbird serverless observability
---------------------------------

Dashbird, on the other hand, doesn't reinvent the wheel. It just **makes it easier for developers to debug** their Lambda-based applications without overcomplicated UI and congested on-screen information.

![](https://mk0dashbirdioprthk8x.kinstacdn.com/wp-content/uploads/2020/10/j7to0v5b2pog1gk3as8y.png)

Take the invocations logs view. With **Cloudwatch** you'd normally see **all your invocations in one screen**. You'd have to **manually sift through** all the logs to find the particular invocation you were looking for in order to debug the app. Now imagine you have 10, 50, 100 functions. **It can get out of hand real quick!**

Switch back to **Dashbird**. **All the functions are neatly listed** under the Lambda views and clicking on functions will **list the invocations** for that function starting with the most recent ones. You can also easily sort by:

-   Highest throughput
-   Most errors
-   Alphabetically
-   Slowest response time
-   Most time consuming
-   or just search by a keyword via our global search function

When the app goes belly up, you need a way to **quickly debug the problem** and you REALLY can't spend time trying to figure out what you are looking at for 15 minutes.

The logs themselves are **formatted** so the information is **interactive** which is extremely convenient for **large objects** but if that's not your style you can always switch back to "**raw logs**" and have it displayed similar to how Cloudwatch shows logs.

On top of that [Dashbird](https://dashbird.io/) has a cool **incident management platform** that allows you to **create custom policies** for alerts. You can then **select a channel **from which you want to get that alert and it can be Email, Slack, webhooks, or SNS. You'll **never miss a warning, error, or just info** about what actually matters to you!

Another cool feature that Dashbird has is the [project views](https://dashbird.io/blog/group-aws-lambda-functions-dashbird-project/) which allows you to **group certain functions** in a project and **monitor those as a group rather than individual functions**. This is extremely helpful for **microservices running on AWS Lambda**.

![dashbird project view
](https://mk0dashbirdioprthk8x.kinstacdn.com/wp-content/uploads/2021/04/2021-02-22-15_32_05-Window.png)

Search for a keyword across Lambdas is a big crowd-pleaser too, as well as the filters which allow you to bring up **cold starts**, **retries**, **timeouts** and more.

I could go on and on but I think I've made my point, but in the unlikely event that you are still not convinced, check out this comparison table below between Cloudwatch vs Dashbird that shows a list of the main features each service has to offer.

AWS Cloudwatch vs Dashbird
--------------------------

![](https://mk0dashbirdioprthk8x.kinstacdn.com/wp-content/uploads/2021/04/Dashbird-vs-AWS-Cloudwatch-5.png)

Wrapping up
-----------

Have I spoken about every little detail that these two wonderful products have to offer? Definitely not. Have I been a bit biased with my comparison? Maybe. Is it worth taking the time to try it yourself? Abso-freaking-lutely!

Want to up your game in serverless monitoring? Then check out [Dashbird app](https://dashbird.io/failure-detection/). It's **forever free **to use for smaller infrastructures (up to 1m/monthly invocations) or [pick your own package](https://dashbird.io/pricing/) for more monthly invocations.