Stackify Reviews

Although the decision to implement Stackify was not mine, when I took over the position, it was one of the tools that were being used by the company. We were using it for APM management, infrastructure monitoring, and log aggregation.

One of the features that we loved the most, is we've been able to create custom dashboards. The company I worked for is an umbrella company. We now have smaller departments under this particular company, each of them standing by themselves and each of them has its own independent development teams. At this center, we have three departments - we have security, infrastructure, and DevOps. Everybody keys into the offering from those three.

At a particular point, we needed to bridge the gap between the business guys and the tech guys and had to create dashboards based on metrics from Stackify for individual businesses. The business guys, in layman's terms, could see how well the infrastructure was doing and it was also a driving point for business, with the technology decisions. For example: How much money do we need to spend on which server for how long? Which of them do we need to upgrade and why? It allowed us to be able to tell that story easily since we could securely share pre-configured dashboards and the dashboard was responsive. The alerts were on point and it allowed us to succeed in that venture.

The solution is stable and reliable.

It's scalable.

The initial setup is easy.

They need to improve non-.NET infrastructure.

We always had difficulty when it comes to reporting or metrics that come from Linux operating systems and Docker containers. For anything that runs within the Unix environment, we always had problems with them, however, if it was a document-based application, Stackify was 100%, it gave everything. Now, the aggregation agent, the metric agent for Stackify for Linux, collects everything. When I say everything, I mean, everything. It collects so much information that we now started to term it as useless data as all that ingestion will just come in and overwhelm your log retention limit for the month and really this spike up your cost at the end of the month. You'll need to do a lot in order to train down the data coming in from all your Linux environments, to get to what you really need, which actually takes some time as well.

I would like to be able to see metrics about individual running containers on the host machines. Stackify has not really gotten that right, as far as I'm concerned. Netdata has done a better job and New Relic has also done a better job. They need to improve on that. We need to be able to see the individual resource usage of containers running within a particular host.

I've used the solution for around four years. 

The solution is stable and reliable. There are no bugs or glitches. It doesn't crash or freeze. 

The product is scalable as long as your payment plan allows you to do so. You can add as many users as possible.

We have between 80 and 100 users on the solution. 

We don't need the help of technical support. The documentation would suffice if you need help. Community engagement also does the trick.

At the time that Stackify was adopted, I know for a fact that New Relic was still working on their product. According to the reviews, Stackify actually came up on top, if you are talking about .NET applications, which the company basically almost did everything about, all the products being developed were .NET based. Stackify seemed like the logical choice to go with.

The initial setup is straightforward - especially if you've been doing it for a long time. You just install the agent and let it run and that's basically it. I also like the integration with the software development ID. Stackify automatically has to collect metrics about your application and the client signature is also very, very clean.

We did not deploy Stackify on-prem. This is on the cloud. All our agents were pushing data to the cloud. I'm not sure how long the deployment took.

We had a monthly billing and license fee. Apart from that monthly billing, I'm not aware of the initial costs.

The price is variable. It depends on how much data we have received in that particular month. Usually, it goes up to $2,000, or, at times, $3,000 USD per month.

My company is a customer. 

I'm not sure which version we were using. The company where I used Stackify, I'm not anymore. While I was with them, I was the head of DevOps. It was basically one of the tools I primarily administer.

I have not had experience with Stackify as a free user. If you would want to use Stackify as a beginner, your needs would not be properly satisfied by Stackify. You would think Stackify is overkill for your new business. From my perspective, I would advise the person to probably go to Netdata, as it's open-source and it's free, or use Datadog for aggregation and the like. If this new user is an enterprise that can bear the cost and if the majority, if not all of the applications are written in .NET, or if they have a need to interface with their business leaders and share metrics about how the infrastructure is doing, then Stackify will be a very good choice. 

I'd rate them six out of ten. I want them to improve on Linux systems and give users much more freedom to select the kind of metrics they want to pull in from the infrastructure.

One thing that happens as a new user on Stackify, is when you install the agent it pulls everything and if you're not careful, your log allowance will just be exhausted as you are actually pulling too much data. Stackify should make it flexible by letting you know that these are the metrics that will be proven. I was feeling as if they were being tricky by sending you special particular nodes and you see every data point has been checked already - every single one. All of them are accumulating in the log base and before you know it, your allowance is done, it's finished. When that happens, everything freezes. You get no metrics, no analytics, nothing whatsoever, as you've exhausted your limit.

The use case for Stackify is for checking application performance. It's also used for logging purposes, particularly error logs and information logs. All information from a particular application goes to Stackify.

For example, if someone is making a request to an application then it crashes, I want to know what happened and what the root cause is, so I go to Stackify to get information about the error.

If an application is taking up so much resources, or if a particular resource power is spiking up in terms of resource utilization, I usually get the logs from Stackify.

If an application is down and my customer calls me and says he can't work with my application for whatever reason, I go to Stackify to get the URL logs.

Most of the time, an error occurs when the resource utilization on my server is very high, so I'll see where the problem lies through Stackify.

Stackify adds value to the business because it reduces the time spent on resolving customer complaints. For example, when a customer calls, and I've been working in the FinTech space for quite a while now, and in FinTech, you don't want to keep your customers or users waiting, so if someone is trying to take a loan now and there's an error, instead of waiting, if I'm going to the code to go and run a test on my local machine, I can just go straight to Stackify, then I'd get the stack trace error there right away. This way, I'd know where to limit my search, so I just go to my settings and look at the stack trace error, specifically look at the line being complained about, and then solve it. This reduces the TAT and reduces the time I'd need to spend debugging that particular issue.

If Stackify wasn't there for me to use, or if I don't have a proper logging mechanism, it means that I have to go into my code, run it locally on my system, try to reproduce the same scenario, and then if I'm find able to see it, then that's the only time I can start working on the error. Having Stackify means that I can more quickly see the stack trace error and the particular line of code that the error is coming from, so I can go back, narrow my search with that, and then just work from there, so Stackify helped in reducing the time in terms of resolving issues.

The solution also gives me knowledge in terms of the resources on my machine. For example, if the RAM on my server has gone low, Stackify lets me know because it shows me that the resource utilization is on a very high level. If resource utilization gets to a certain point such as 90 to 95 percent, it's going to freeze the application and when that happens, the users will not be able to use the application, so I can always go to Stackify to check.

When you try to send any request, you'll notice that the application will just be rolling or processing perpetually without getting any response from the server, but with Stackify, you usually get alerted on resource utilization. When your resource utilization gets to a certain level, the solution will alert you, and this is a feature my company enjoys because before it gets to that level where customers complain, Stackify will notify you of the issue and you can more quickly resolve the problem.

The solution can also take out some solutions, or it will scale horizontally, which means I need to go and add more resources, in terms of RAM. The same goes if there's a need for a CPU. Stackify, in a way, prevents you from being reactive because as soon as you get the alert from the solution, you just go and resolve the issue before it happens, or before your customers even take notice.

The filter feature on Stackify is one of the features I found valuable. It's awesome. When I want to get the application logs, the solution gives me many filters. For example, if I want to get logs from my test environment, the option is there for me to select the environment from Stackify, and you can also select the particular application, and you'll see the information you need there. The filter feature alone and the fact that Stackify offers a lot of different filters is what I like the most about the solution because I've used other tools with the filter feature, but the filtering was very difficult, versus Stackify that has good filtering. On Stackify, you can filter the information by the last one hour, or the last four hours, and you can also select the date range and specify the timestamp, then the solution will give you the information based on the date range you specified.

Another feature I found valuable on Stackify is its rating feature because it tells you how your application is faring. For example, a rating of A means excellent, while a rating of F means very bad, or that your application is not doing well at all. The ratings are from A to F.

I also like that Stackify helps you in terms of load management because the solution gives you information on overutilized resources.

These are the most valuable features of the solution.

I've not used Stackify for a while, and I'm currently using a solution now that's not as good as Stackify. Among the solutions I've been using so far, Stackify has been one of the best for me, but there's always room for improvement. For example, I don't know if it's just me, but when I try to get the log from Stackify, sometimes it doesn't appear in real-time. It takes a few minutes before the logs appear. When I redeploy my solution and the application starts, I don't see the logs immediately, and it would take two to three minutes before I see the logs. I don't know if other customers have a similar experience. It's the wait time for the logs to appear that's a concern for me, could be improved, and is what the Stackify team should be looking into.

In terms of any additional feature that I'd like added to the solution, I'm not sure if Stackify has a way to export logs out. I've been trying to do it. On the solution, you can click on a spiral-like icon and it shows you the entire error, and I'd prefer an export button that would let me download the error and save that into a text file, for example, so it'll be available on my local machine for me to reference it, especially because the log keeps going and as you're using the solution, the system keeps pushing messages on to Stackify, so if I'm looking at a particular error at 12:05 PM, for example, by the time I go back to my system and would like to revisit the error at 12:25 PM, on Stackify, the logs would have gone past that level and I won't see it again which makes it difficult. When you now go back to that timestamp, you don't tend to see it immediately, but if the solution had an export feature for me to save that particular error information on my local machine for reference at a later time, I won't have to go back to Stackify. I just go to that log, specifically to that particular export that I've received on my local machine. I can get it and review it, and it would be easier that way versus me going back to Stackify to find that particular error and request that particular information.

I'm not using Stackify at the moment, but the last time I used it was three months ago, for performance regrouping and monitoring at the company. Overall, I've used the solution for almost two years.

Stackify is a stable solution, but that's also relative, similar to its scalability. For example, if you're using it on-premises and your server is always going off and on, then Stackify won't be stable for you, but if you're using it on the cloud, for example, on Azure, or AWS, the solution will always be available to you. Its stability is also relative and would depend on where it's being used.

Stackify is a scalable solution. In terms of how easy scaling it up is, that would depend on who is working on it. For some people, it might be easy to scale, but for others who don't have in-depth knowledge about how Stackify works, it might be difficult to scale. Judging from what I've seen so far, I find Stackify easy to scale.

I've never been in touch with the technical support team for Stackify. If I were to get in touch with support, it would be because I wanted to request a feature, for example, I would contact the technical support team to request the log export feature, or any other features I need, to be available on Stackify.

I'm not sure if the initial setup for Stackify was complex because I wasn't the person who set the solution up. I was assigned to a legacy solution, so I was just onboarded on how to use Stackify, and it was my first experience with Stackify. Same with other solutions I worked on, you just replicate the same settings across other applications, so that was straightforward. If you've done a process before and it's working, of course, if you want to do it again or replicate it, it will take you a lesser amount of time because you don't need to start thinking of how to reinvent the wheel as you already have a working prototype. What you just need to do is go to your prototype, copy the settings, make some modifications, then you're good to go. The process is usually fast, but if you've not done it before and you're trying to do it for the first time, I don't know what the experience would look like, but for someone like me that have used it before, if I want to replicate it on a new application now, it will be faster because I'm already familiar with the environment.

I'm pretty much sure setting up Stackify will be straightforward compared to other solutions I've worked on. For example, setting up Spinnaker was not straightforward for me at all. I kept struggling with it, but for Stackify, it's pretty straightforward because I'm not a novice to it. Some people might find it difficult, but for me, I'm sure I'm not going to find the setup for Stackify difficult again.

As for the deployment time for the solution, it would be in proportion to the size of your application. If your application is very big, it would take longer, but in my case, particularly on the solution I was working on, the deployment time took a maximum of five minutes. Before the application starts pushing to Stackify, it will take an additional two to three minutes, and this was the lag I mentioned previously. When your application starts working and you call an API, for example, even the REST API, and you start printing, and you want to see the information, you still have to wait for a few minutes to see it in the log.

The deployment is automated because there's a pipeline ready. Whenever I want to deploy a solution, I just use a tool called Octopus which has been configured by my company. I do my deployments on Octopus and I also do the deployments on Stackify. Stackify is just for my company to have visuals, particularly visualization of what is happening on the application side and the server, but for the deployment, it's done on Octopus. The tool just requires a click of a button so the deployment is really quick. My company would have done the setup already, so all I need to do is create a new pipeline for a solution, and to do that, I just get a template of one of the existing projects, stay within the parameters, and I'm good to go. As long as I've added the configuration for Stackify for my solution, the moment the application is deployed completely, it pushes logs automatically to Stackify, and it's pretty much straightforward for me.

I don't have the pricing information for Stackify because it was already set up by the DevOps team, so I just came onboard, was introduced to the solution, then started working with it. I never got to find out about the pricing, and the only time I'd search for pricing information about Stackify would be when it's for personal use.

The team was looking into another solution before choosing Stackify, but the management didn't approve it. It was just a "brief touch" and I just went into the basics of it. I couldn't get much information from that solution because the management wasn't willing to pay the support fee as that solution was quite expensive then, so it was discontinued. My team was using an on-premises server and it had to go through the server and the application logs, and that could have discouraged the management, so the budget wasn't approved. Whenever there was an issue, the team had to start writing commands to pull logs out, so it was hectic, so when I saw Stackify, it was "Wow. Okay, so there's something like this out there that you can use." Another tool that I've used is Spinnaker, but it's not as user-friendly as Stackify.

I wouldn't know if the version of Stackify that I was using was the latest at the time because I wasn't tracking its updates or keeping track of its versions, as long as it's doing what I needed it to do.

In terms of maintaining Stackify, I'm not sure if there's regular maintenance being done, because that's from the engineer's perspective, but most of the time, I hardly notice any changes. DevOps, the team responsible for the maintenance and management of Stackify might be working in the background without me knowing because my job function differs. I'm a backend engineer so I don't have maintenance duties and it's not my responsibility to look for issues in Stackify. I don't dive into DevOps issues unless it has something to do with my application, for example, if I'm trying to deploy my application and it keeps failing, but on my local system, it's working. That's the only time I'll come into contact with the DevOps team to get to the bottom of my problem. I'll get on the call with DevOps to solve the issue, and I rarely get to work with DevOps or cross paths with the team because my work is different.

The company is a FinTech company, so virtually all engineers use Stackify because if you need to get information, for example, if something is happening in the production environment and you need to get information, you must check Stackify. There is no way you can write an application and you don't post the logs. Stackify is the visualization tool in the company used to monitor application performance and also get error information and logs. The number of Stackify users currently, within the company, is a hundred or so, including quality assurance personnel who check the logs from time to time, especially when working on staging or UAT environments when engineers aren't around. People with technical backgrounds also go into the solution to get the logs and send those logs to the experts within the company.

My advice to anyone who wants to use Stackify is to go for it because my experience with it is good. I've used it and it was awesome, especially when compared to the solution I'm currently using now. If you need a new visualization tool, go for Stackify. You can always compare Stackify with other solutions, including its features. It's a solution I'll always recommend.

I'm giving Stackify a rating of eight out of ten.

We use Stackify for server monitoring and application monitoring. We have several servers spread across AWS, and we run processes. Some of these processes run on Docker containers and some on Windows services. With Stackify, we can see the server utilization and proactively set alerts in case of any incidents.

There are a few valuable features. The performance dashboard and the accurate level of details are beneficial. For example, we used the solution to detect a memory leak simply by checking the performance dashboard over a range of hours when the incident occurred. Regarding performance, we can order requests by the response time. The performance tab is one of the best features with how the information is displayed. It visualizes the performance information you want to know.

In addition, we also appreciate the scoring. We can check the application score even without a reported incident. So if an application score changes, you know something is wrong.

When Stackify completes drill downs, sometimes there is a block of execution pipelines, and you cannot see the details. It does not allow you to analyze the block of code, and we are unsure what that means. Also, there is a bunch of middleware or native framework execution that Stackify does not analyze, and it is difficult to tell what the issue is.

The search feature could be improved. On the trace dashboard, the search box is not intuitive enough. For example, you see search by URL, but it is unclear if you need to search by absolute URL or URL segments. A placeholder in that search box would make a big difference.

Also, using Stackify with Docker, there could be better documentation. It might be a knowledge gap, but sometimes we get it working on a Docker container and even with the same configurations, it doesn't work, and we end up searching for documentation on the internet.

Another improvement would be the agent memory utilization, which led to our recent reevaluation. For example, you could have a 16-gig server, and the Stackify agent takes a bulk of the memories.

Regarding additional features, it would be great to add availabilities of the applications. Other companies use some metrics to measure their application stability, showing the system's availability within a time range.

We have been using Stackify for about five years.

It is a very stable solution. We have not experienced any downtime from Stackify. If there is any downtime, it is most likely local due to internal DevOps making updates.

It is a scalable solution. We can add more users without any issues. We have also upgraded users several times and also had no problems. All the engineers in my organization are on Stackify, and our development team has around 100 people.

I've used Stackify technical support in a previous role. It was good as I received a response the same day. However, I have not used them in my current company as we have dedicated support internally.

The initial setup was easy for bare metal and was okay for Docker. It involved running a single script, and we were good to go. However, when you build images multiple times, you must repeatedly install things in the Docker container.

In terms of getting everything set up for server monitoring, it takes less than five minutes. We just copied the scripts and executed them.

The licensing cost is calculated on a per-user basis.

I rate this solution a seven out of ten because of the issues faced when we recently moved 60percent of our applications to Docker. It was not easy setting up the instances. This rating is also based on all the other areas for improvement.

We recently evaluated whether we should continue with Stackify and decided to continue. What stood out to us were the metrics and granular details we received. When those features are compared with others, they stand out. Also, the cost is very reasonable. I recommend this solution to others.

I use Stackify for two projects. One is two companies, for nearly two years, I used. One is for exchanging Malaysia. One is in the telecom domain and device instrument platform. For those two companies, we do a performance test and identify the root cause of problems for response framing, calculations, and all those things. I use Stackify a lot. It's good for testing. I use it for identifying how many DB calls and third-party requests there are.

I use it personally.

It is very simple and very easy to configure. The best part is it shows how much response time and how many calls. I can see good usage of DB calls which made me improve my performance analysis skills on the project.

The solution is stable.

The deployment is very fast.

It adds value to code reviews. Whenever a developer has developed a feature and before pushing it can also push the stats of Stackify and check out performance metrics. Based on eh results, he can compare and approve the full request if it makes sense.

In the next version, which I want to try, it'll show the comparison of the old responses of the APS. For example, how much time the old response and the new response with the changes. Right now, I cannot differentiate.

The graphical interface should be able to capture nicely how much time it has taken and it should be very clear. Sometimes it confuses us. For example, what is this APA for? What were the average responses and how many requests have happened? It needs to give a clear picture. They should enable request and response capturing in the Stackify user interface to show what the request for the APA is. Then, it'll be very good.

It should be able to capture the payload. For example, what is the request and what is the response? If it has a nice way of capturing everything then it would be easy. There is no need of using ELK again for logging.

As of now, people will use Stackify or maybe Grafana for seeing the stats of the application or responses, however, it doesn't have the capabilities to show everything. People will go for any exception handling or checking the request and response in the ELK. If Stackify can do this future, then it'll be an easier single tool. It is anyway intercepting the logs, application logs. I don't think it's a big matter to capture extra data with the requested response. That requested response capturing also should be configurable since some people want the question response to be captured and for the people that don't want it, we can use that feature. It can be enabled as desired.

Many people are using different monitoring tools like ELK, LogStash, and Splunk - many other tools. However, if you can make this kind of performance tool cover everything, then they will not shift to other solutions.

It should be easily scalable and configurable in different instances. For example, if the same application is scaled up to differently, it should be easily integrable into Kubernetes pipelines.

They should offer plugins to make it more easily integratable.

For development enrollment, it should be free to use.

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

Up until now, the performance has been good and it has been stable. There haven't been crashes. It doesn't freeze.

I didn't deploy or use this in the production environment that can be scaled across different instances or something. I don't have knowledge of scalability.

I was doing performance optimization and I was the only one using it.

It's very easy. Therefore I haven't had a need to reach out to technical support. I've never needed anybody's help.

It's not easy to set up. It's hard especially for juniors to understand. A more senior person might be better positioned if they understand the concept of performance and interception of logs. They need to have knowledge of third-party requests and database calls, et cetera.

The deployment is pretty fast. It doesn't take much time. It's a fraction of seconds. It's just an agent that will intercept the current application.

I use a trial version for 30 days. That's it. After that, I don't use it much. Whenever any install was done, the installer would use it and test it. I've never paid for a license. I'm a consultant. I'd just use it jumping from job to job.

I'm a consultant. I'm a customer of Stackify.

I was using the latest version of the solution a year and a half ago.

I'd advise others to try and use it. It would be good for a company to take on a corporate license so that they don't have to uninstall it and install it as I do now. Once they install it, it can be integrated with the application whenever they are doing changes in local. They can see the stats before the push to go to the deployment or for a code merge to master. It would be a good thing.

I'd rate the solution eight out of ten.

We were using New Relic, but it wasn't providing us the info we wanted and it was so expensive that we couldn't afford having it on all prod servers. I've been using Stackify in a .net, Azure based webapp, the app is with high traffic subscription service, and solid services is essential.

Having the log and error data as part of the detailed trace was a tremendous help. And seeing all the logs recorded when an exception was thrown is a cool little feature.

In one case we were using Stackify to identify an issue that made the site slow occasionally, it was very hard to pin point the source of the problem. Once installed it was a very fast process and we identified the combination of issues that lead to this behavior. Having the log and error data as part of the detailed trace was a tremendous help. And seeing all the logs recorded when an exception was thrown is a cool little feature.

Better mobile support.

1 year - APM+ and SmartELM

The installation was very easy and smooth, it was nice to have many default monitors already set-up as part of the install so we could see monitors immediately.

No issues. Solid tool.

No issues, we've been scaling our environment quite a lot and Stackify collected the info from all servers including the transient ones

Excellent! Professional and friendly (Actually gave me some tips about Azure that help me solve an issue that was completely unrelated to Stackify)

Excellent! Professional and friendly.

We switched from New Relic and Loggly as it provides us more info at a lower price.

Straightforward

In-house

We've seen shortening of our time to resolution, and we've even identified some issues that we weren't aware of, but were affecting our apps performance

Their pricing is simple and clear and is low enough that we can have it running on all servers at all times.

Yes, AppDynamics, Dynatrace, New Relic, and Microsoft Insight.

I like how Stackify combines capabilities that otherwise required us to use separate tools. The combinations of these tools making it a lot more powerful than many of the other tools in the market.

Few examples are:

See all the logs associated with specific error

Monitor spikes in errors and and specific log search criteria

See the application performance together with the server performance but also the logs and errors trends and how they affect customer satisfaction

We became a more proactive organization, we get notified once trend is starting and can address it in working hours before customers even notice it.

I'm looking to see more performance tools, but heard that they are going to release some.

8 month

No, pretty straight forward.

No.

No.

They have very friendly, professional and responsive service organization.

They have very friendly, professional and responsive service organization.

We had Nagios for monitoring which was very painful and unfriendly and AppDynamics and Loggly.

Straightforward

In-house

Within few hours of install we've identify the source of issue we've been investigating for few days and couldn't pin point. So Stackify with it's low prices returned itself in probably less than a day.

Our day-to-day cost varies as Stackify only charge you when you use it.

So for the error & log management we pay probably about $40 a month and for the Monitoring - as it dependent on how much we scale our monthly is pretty low as well.

Yes, we looked on variety of other solutions, but no other products gave us so much functionality together. We looked at players in the log management market, error monitoring market and app & server monitoring market.