Apica Reviews

We're a banking software company, so we use it for Synthetic logins to test how one of our end users would log into our product for a customer, how long it would take, what loads, and then log them out. Then we test how long it takes to do that entire process.

On the Synthetic side, we only use it SaaS-based. We actually put it through an SSO. We use Okta for an SSO. That's how we're securing our connections there. Security-wise, Apica's got a couple of things in the works that are going to help them out, but they're not there now. In particular, they're coming out with a key chain that allows us to save. You can hash passwords and users, they don't have that right now. Passwords and logins are set in plain text.

Before we had this particular product we were using SolarWinds to do something like this. The problem with that, however, was that was an internal check, which means it was coming from our network. With Apica, we could do the same type of check, and then we could also make a scenario script that would go and click the things we wanted to click, but it would come from an external source that we did not control. That would give us a better baseline for what the customer sees, as opposed to what we expect to see from our network.

We like the scripting features and the scenarios. It allows us to set up exactly how a customer would log in, what they would type in, where they would click on the screen, and then takes screenshots of it so that we can actually see it happen and see what they see at that time.

We also use it for up-down checks for a lot of our websites that we make ourselves for our customers to make sure the sites are up or down. It's not part of the Synthetic side of it, but we also use the ZebraTester. We're actually implementing various homemade tools on our site as well by API.

We use ZebraTester for some of the sites and other things before they even become into the Synthetic side.

It is highly flexible when it comes to websites. There are a few things that it does fall down on, but for the most part for logging into a website to check to make sure elements are loaded on the screen, it's highly flexible. If I don't want a certain element to load, I can block it or I can ask it to ignore it. If I need to check for a certain element, I can do that as well.

As always, within the IT industry, everybody's always looking to upgrade and update everything else like that. Apica has been one of those things but it's really hard to replace because it offers us the unique capability to see what the customer is seeing. A lot of other ones can do Selenium script and things like that, but there's a lot in Apica that we use right now. We utilize a lot of the scenario options in Apica right now, and there's a lot of other ones that do parts of it, but it doesn't do everything that Apica does.

Apica is indispensable in a few things that we do. It currently is the only one that we have that catches CDN outages. We have many tools that monitor our customer sites, but a lot of those are API logins. If we had a CDN outage and the site didn't load all of its elements, we wouldn't be able to tell that. Apica can tell that because it's looking for particular elements on the screen. Indispensable may be a strong word, but we do highly rely on it for some things.

We use Selenium scripts and we were able to do more specific checks, so it makes it feel like we're actually a customer logging into one of our sites, checking their accounts, and logging out.

The scripting feature has kind of saved money and resources. When we first got it set up, it was a pain because we didn't have the script set up before, but now we have it setup and it's running on multiple checks. Multiple checks, meaning, our Synthetic login checks range around five to 550 checks. Now when we have scripts set up to make the Selenium check, I can pump out new Selenium scripts for one of our online banking customers in five minutes.

Alerts are always accurate, but they might not always be useful. Apica alerts on two different things: one, when an element that is in the script cannot load, and two, when a part of what's loaded comes up with a certain internet error code, a 500 or 402 or something like that. It's always accurate because those things are always not doing that, or they're getting the errors, but it may not actually be as useful. To deal with that, we generally either have to block the URL that's throwing the error code or whatnot, or we have to verify the elements.

It's very accurate but sometimes not useful. It's also noisy. When Apica alerts, it does not have a pull-in time or anything else like that, unless for elements or error codes. It does for SLA times and variances, but not for the other ones. It could be that it's a one-time blip and something didn't load on the screen, it alerts immediately right then. If it loads the next time, it's not going to alert. If it's still set up, it alerts. It can be noisy.

This level of alerting accuracy has saved us time and money in operational costs. With CDN issues, it lets us know, for instance, that we have a homemade monitoring system for our products as well that monitors to make sure that things that should be there are there, but it doesn't actually take into account if the webpage itself is loading. A number of times we've had major CDN outages where our homemade monitoring tool is fine because everything is loaded by an API, but the webpages are not. When that happens, Apica tends to go alert hard and that lets us know that "Hey, we need to go check over here as opposed to over here." That saves us time and money on troubleshooting.

We have two different approximations in terms of how much it's saving us. The way that we do our major incidents, is that we do it per customer. If we have five customers down for five minutes, that's 25 minutes of downtime. I don't have an exact number. I know that things like that when it affects our entire environment are pretty substantial.

It has also saved costs involved in managing monitoring. It has at least saved us in the cost of that it gives us one pane of glass to go to for Synthetic monitoring. I can actually send one of our analysts to go look and if they want to know if a page loaded, they don't actually have to go log in, they just have to log into Apica and check to make sure Apica's running well. That saves time, which saves them money.

Alerting needs improvement. It's a little noisy. It needs some better options. Currently, they have an issue, when you set up a Synthetic monitor, you can set up where it's monitoring from a data center that Apica owns. However, for each data center that you attach to a monitor, that's considered an extra license. That's a bit iffy. They're usually behind on the version of Chrome that they're using for the Synthetic monitors. Currently, they're using Chrome 85, they're 11 iterations out of date. They're trying to get that fixed up with something called Evergreen, which will basically be a Chrome browser that'll stay constantly up to date, but it hasn't been implemented yet. 

The problem with that is that we generally test our product with the newest versions of Chrome and everything like that, so sometimes we've run into issues. Also, when they updated to Chrome 74, we lost some monitoring capabilities that we had before that did not transfer over with this new version of Chrome.

I'd like easier access to the API. Their API, it's not bad, it's just bulky. It's a little unwieldy in the way it has to be used. One of our app developers is currently working with them and he wanted to do a number of calls to the API, and he was not able to do that. They had to make special changes to our API to make the number of calls he wanted to make. It didn't seem to be scaling as well as we thought it would. But they worked with us to actually get it to do that. That's a plus point.

I'd like to see more abilities to do mass changes to checks in the GUI, in the interface. Things like setting a mass amount of blocks for checking a bunch of checks and saying, "Make sure that this URL is blocked on all these checks." Currently, we can only do that through the API, and last time we had to do that, we actually had to use Apica support to do it. 

Finally, they have an audit log system called Journal. However, it can only check, if I remember right, two weeks at a time. That becomes really difficult when you need to check on something that you need to go back multiple times and you don't know the exact dates of the thing that changed. For example, I had a user who got changed in one of my checks and I needed to find out when it got changed. It ended up being three months ago, but I had to go back in two-week increments until I could find it. Their Journal, their auditing system, needs a little bit of work.

We've had Apica for five years. 

We are using the SaaS portal.

The stability is not bad. We've never actually had an issue with Apica, the product. The alerting really comes back down to how this thing alerts, how the alerts are sometimes not useful. That's the worst I could say about the stability. We can turn them off or we could filter them through a third-party.

From what it does, it scales pretty well. I can easily go in, pull on a check, assign a scenario to it and boom, I'm done. I've done that many times. A couple of weeks ago I spent the day creating very specific Selenium checks for very specific parts of a customer's website to make sure that they load properly. It handles it quite well.

We have roughly 100 users using this solution.

We take Apica data and we send it to our data warehouse so that we can do SLAs for our customers. There's me who sets up all the monitoring in there. And then we have our NOC, who will go in there and they use it to actually make sure sites are up and everything. It's used throughout the company in all ways: business side, maintenance, and monitoring.

I do the maintenance of Apica. 

I have 683 checks. For the Synthetic login, the checks, it's 400 checks. Those are the ones that we mimic the login like a customer would log in. For the VT checks, which are basically just up and down checks, we have 112 of those. That's not just our customer sites, we also use this product for our site as well for corporate sites.

We do have plans to increase usage. When a new customer gets added in, they get a check as well. Every customer gets a check.

Support has never been a problem. Their support is top-notch. We either email or get our client experience manager on the line. They have been top-notch, willing to help, willing to go the distance. I have very minimal complaints about support. The one complaint I did have, they actually addressed it very quickly.

We started with SolarWinds, and after that, we moved to Apica. We then got rid of our SolarWinds integration and went to LogicMonitor. LogicMonitor has its own website monitoring tools. However, the problem with LogicMonitor's website monitoring tools is that it's very hard to set up a script the way that Apica does. They also don't provide screenshots of what happens. We've looked at a number of other vendors as well. The problem always comes down to it doesn't do the things that Apica does.

The initial setup was very complex. I wasn't even part of the initial setup, but I know it was very complex because we needed an external source for our checks, but we needed to be able to mimic logging in like the customer did. This was back in December of 2014. I have a feeling nowadays though, they probably have this down to a fine science of how to get people implemented and their stuff up and running.

We have seen ROI. We use it for all of our customers and it does help us. A lot of times it can catch things that happened to the site, but don't happen to the API. We've seen a good return on that.

Pricing is based upon not so much users, but the number of checks you're going to create. Make sure when you set up an account with this, to request more licenses for checks, for any type of check, than you actually need. This will save in the long run. They're really good about setting this up and getting you more licenses but there's always a cost with that.

If you think you're going to need 100 checks, make sure you get 110 licenses. Then remember if you want to do multiple-site checks, not just one-site checks, you're going to get a license for each site.

With all companies, you get the base product, but the base product's not all that you want. You want it with a whole bunch of other stuff with it. We can safely assume that there are probably other costs to add things. Things like additional integrations with other products are not included in the standard license. 

The biggest lesson I have learned from this solution is the sheer number of sites that can load when you load one website. We do online banking, but when you load online banking, it also loads 50 other URLs as it loads through there. That might include Google, Facebook plugins, or things like that. It has really opened my eyes to how many things load when you just open up a single webpage, even if there's that much on the webpage itself. It's very comprehensive when it comes to website monitoring.

I would rate Apica Synthetic a seven out of ten. We've had our problems with it and we're still waiting on some add-ons and features, but for the most part, it's never wrong. It's just sometimes noisy and feels old. The UI is very basic. It's not bad, it's not ugly, but it's basic. It uses old browsers. 

I worked with an iGaming company called Betsson, which is a very big operator. We used Apica to monitor our brands and our white labels. We used different product features, simulating user experience such as logging in to the website, playing slot-games, registering an account, etc. We used various aspects of the product.

What I like the most is that Apica can simulate different browsers and different versions of desktop or mobile browsers. You can also add certain custom scripting, which elaborates the functionality more, like logging in with a test account or making a sports bet. The most critical function of Apica is that you can monitor your websites from different locations.

In terms of operations, the solution is quite easy to maintain. It has a very useful user interface. Since it's cloud-based, you don't need to maintain any infrastructure related to the tool, and it's quite convenient.

Apica should add more features and integrations with different tools and certain ticketing systems, like ServiceNow. As a user, you would want to add checks in more locations.

I used Apica for 3 years

Apica is a very stable solution.

I rate the solution a nine out of ten for stability.

About 12 people in my organization were maintaining and monitoring Apica.

Since we had enterprise, we had SLA support, which is very good. We never had any issues with the support. When we contacted them, the technical support team replied very quickly.

Positive

It's a continuous improvement, but the solution's initial setup takes one or two months, depending on the size of your organization.

The initial setup of the solution depends on the organization. It's very easy to set up the solution if a company has basic checks. It may take longer, around a month, if you need custom modifications.

The solution's pricing is not cheap, but it is in the midrange. The pricing depends on the scale of the organization using it. With more users, you will need licenses to maintain it, and it will get more expensive.

Apica has different types of integrations with Slack email and other tools. Once the response time falls under a certain threshold or when something degrades, the solution's alerting system immediately informed us so that we could take action accordingly.

As an iGaming operator, we worked in different markets. It is very efficient to monitor your brands in the locations where your markets are located. You get the closest to your user base. It was very important for us that we could monitor from the exact location where the players were playing the games. That is one of the main features of the tool. I would strongly recommend Apica to users who have B2C clients and websites in different locations.

Overall, I rate the solution a nine out of ten.

I use the solution in my company for performance testing. As the tool is useful for performance testing, it is maintained in the cloud environment.

The product is useful to check the performance of applications and our company also integrates it with other tools since we have a good bandwidth as well. The tool is useful in areas associated with server-side metrics and client-side metrics. When you talk about the client-side metrics, the tool gathers information like whether it has a 90 percent response time and the average response time.

Compared to NeoLoad, JMeter, and LoadRunner, Apica offers many features. With Apica, our company gets to use some direct options. My company is planning to use the same features from Apica in other tools like NeoLoad or JMeter. It takes time when using the functionalities available in Apica in products like NeoLoad or JMeter. It is very easy in Apica to take care of the scripting and adding the input files.

At the moment, Apica is fine, and our company has not faced any issues with the tool. There are some kinds of improvements needed in the product. If you are adding any input file, the tool fails to capture the path. How to work in the scripts and update the path takes time, making it an area where improvements are required.

I have been using Apica for two and a half to three years. I am a user of Apica.

In Apica, once you are done with the scripting, you need to upload them into ALT. Generally, if you have around 100 or 200 scripts, sometimes it won't be able to capture all the scripts. My company has reported the aforementioned issue many times to Apica's vendor, but they have not been able to provide us with a proper solution. In our company, we work with around 200 web applications, and in some applications, we have more than 100 to 200 scripts. Though the 200 scripts get uploaded in ALT, the problems stem from the fact that Apica is not able to capture all the scripts.

It is a good solution in terms of scalability.

Most of the people in my company use Apica for different projects. In my team, around thirty people use the product for performance testing. Around ten people use Apica's synthetic monitoring capabilities.

My company has contacted Apica's support team to notify them about the issue related to the product not being able to capture all the scripts. Though my company does consult the product's support team by scheduling the issues, the response provided by Apica does not match up with our expectations. My company has received a support email address from Apica, which is made exclusively available for my organization, and so we use it to contact the support team.

Previously, my company used LoadRunner.

Speaking about the setup phase, my company has integrated Apica with ZAPTEST. If you want to add any tools related to load testing, we can easily do so without any difficulty.

The solution is deployed on the cloud.

Though I am unsure about the exact price of the product, I am sure that Apica's price will be lower than LoadRunner.

In Apica, debugging and other such areas are easy.

I would definitely recommend the product to those who plan to use it. Compared to the other tools in the market, Apica reduces the work time associated with scripting.

It is easy for beginners to learn and use Apica. With every tool, the concept remains the same, but the implementation may differ. With Apica, everything is easy to learn and implement.

Considering that it is a tool that makes it easy for everyone to deal with scripting, and since it reduces the manual effort required, I rate the tool an eight out of ten.

We have an eCommerce company. so we manage a lot of online stores. Our main usage is to make sure that our store web pages are different types of web pages, so there can be a homepage, search page, or product list page for each online store that we manage worldwide. We leverage a lot of Apica Synthetic probes to make sure that every store is available and responding as we expected worldwide. This is to ensure that there are no outages in specific parts of the world. Also, we collect some performance metrics, like response time, time to first buy, etc.

We are using the web-based service. While we do have some on-premise probes installed, we use the service on cloud the all the way. We installed the probes two or three months ago.

We see the benefit almost every day. It allows us to be alerted whenever there is a store that is not responding properly around the world. We do have a network operation center (NOC) who receives these alerts, immediately checking if everything is okay. There are some false positives, depending on the website configuration that we are checking. Other times, the alerts are real. We receive a very quick alert through our NOC so we can immediately check and try to find the root cause. This is our biggest benefit. 

Another benefit that we leverage is the creation of reports every month, regarding the availability of all our stores. This is something that is needed by the executives of our company. They want to see this report with the SLA availability of the stores. We are able to do this straight away with Apica Synthetic.

We don't have a lot of very complex monitoring cases because most of our checks are basic HTTP checks. However, in some cases where we use the solution with ZebraTester for scripts and monitoring, we have been able to properly import the scripts used on other platforms, reworking them so that they would work with the platform and have no issues.

The features that we use probably 99 percent of the time are the HTTP and HTTPS checks. We set up a lot of them. This is 99 percent of our current usage of Apica Synthetic as well as some full browser checks, but this is a lower amount. We also use some scripts that utilize the platform, but our usage of them is very small. 

An very important point for using Apica is the ability to have Chinese probes, which is not common among these types of tools. Other important things were the Grafana native integration and PagerDuty integration, which are all tools that we use extensively.

When we started using Apica Synthetic, we lacked a very important feature that was readily available in the following months. The alerting is usually very good - it allows if any websites or web pages are not responding properly. What we missed was the ability to aggregate alerts. This means that if we were monitoring one website with multiple probes worldwide, like Tokyo, France, and London, then Apica Synthetic would initially alert us if any of these three probes were responding with errors. We wanted a less sensitive alerting. For example, we could be alerted if the website was unavailable from all three probes, not just one. However, an aggregated check was not initially available. 

We do have two main open topics with them, regarding the features that we would like improved or added. 

1. The reporting part that we use for our executives needs a bit more customization capabilities. Right now, you can use only the three main templates for reporting. We would like to be able to customize them. 
2. The management of their single-sign on authentication does not 100 percent fit our requirements.

I have been using this solution for around two years.

The stability is very high. We had probably one outage in two years. I am very happy with its stability.

It is very scalable. Of course, scalability comes with a cost. If you need to scale out, that means you would need to use more of your licenses. However, that is reasonable.

There are mainly three to five administrators of Apica who check the platform, configure things, etc. These administrators are all part of the monitoring team. Plus, there are another 40 to 50 users who access the tool to check the collected data. Sometimes, they will also add some checks, but most users only check the outputs.

Right now, we are around 80 percent adoption. We would like more people to use it on our side. On the Apica Synthetic side, we would like to cover some additional checks that we haven't had time to add.

Their support team is very helpful. If we miss something, they make sure this is easily taken into consideration in the future. This is very important for us, because we tend to evolve pretty quickly. Also, in terms of requirements, they are very responsive, which we really appreciate. On a scale from zero to 10, I would say that they are very close to 10. I would probably give them a nine. I am not giving them 10 because 10 is perfection. I am leaving some room for improvement, but it is a very high rating in my opinion.

For now, the coverage is 100 percent of what we need. We were using another tool before migrating to Apica Synthetic. So, we made sure that all our needs were fulfilled and Apica Synthetic was covering all those needs. 

The reason that we switched was mainly because the previous solution that we were using did not have all the features that we needed. It was not really well-maintained. Often, it had some outages, which were unplanned. Overall, its usability was very low. So, it looked like a very old, not updated tool. So, we needed to find a better tool for our purposes.

We were using Broadcom ASM. I know they changed the name a few times, but initially it was owned by CA, and now it is owned by Broadcom. 

The initial setup was very straightforward. 

The solution went through our InfoSec review, which is something very important for us. The fact that we can deploy the service in a hybrid way is very useful because we do have some web pages available that are only using our internal network. We used to have two separate kinds of solution in order to monitor Internet-facing websites and internal ones, but thanks to this hybrid solution with the on-premises probe, we are able to use only one tool for both use case scenarios. This is very good for us.

We did use the professional services provided by Apica to help us with the migration, since we were migrating from an existing tool. Therefore, it was not from scratch. So, we leveraged them, and it was a very straightforward process. I would rate the level of support that I received during the migration as a nine (out of 10). This level of support helped reduce the time and costs involved in switching. Without the support, we would have had to do that entire job on our own. This means a lot of man-hours, and we couldn't afford that much because we don't have a lot of free capacity.

A few times, they solved some issues or problems with what they were importing or moving. They notified us, providing us with a better option. So, they anticipated our needs.

The migration took around four to six months. 

One person from our company was involved in the migration. This person's role is as an application performance specialist. His main job is to manage our application performance and availability tools. During the scope of the migration, he supervised that the checks were migrated properly as well as responding to Apica in case they had some issues or suggestions.

Apica Synthetic is used to avoid losing money, rather than make money. 

Our JMeter script is loaded into the Apica Synthetic platform. If Apica Synthetic didn't have this feature, we would have been forced to either choose another solution or add an external service to adjust for this purpose. In this case, they saved us money by allowing us to use only one tool.

The aggregated check has since been implemented by Apica, and now we are using it. Thanks to this, we are seeing when there is really a problem instead of just seeing some glitches and issues with the alerting. This has saved us time in operation costs because instead of having to check every time for just one probe that is failing, now our NOC center is able to focus on the important ones. We are saving a third of the alerting, e.g., if we were alerted and had to check three times a day, we are now doing it only once. 

Apica Synthetic reduces the time required to fix issues. If our website is down for hours, then we lose money. So, the less time it takes for us to be alerted of a problem, then the less money we lose.

The pricing is very reasonable, but it is not cheap.

We did some PoCs with other tools before selecting Apica Synthetic.

I would recommend it to get in touch immediately with Apica Synthetic support to have a chat with them and discuss best practices. They are usually very helpful since they are knowledgeable about the tool, so they are able to suggest the best way to implement checks.

I would rate this solution as a nine (out of 10).

We have various tools, applications, and websites and the use case for Apica is emulating user actions on those sites and in the tools. We use it for proactive action. Before the user starts getting errors, Apica will alert us because we have it monitoring the same actions we expect the users will be taking. Once Apica detects an error it will notify us so we can take necessary action, before it becomes widespread and users start to report it. Apica is doing an important job in monitoring because our company offers services through those sites and the application.

We're using it on-premises and we're using their agents on their cloud.

Because we're using this product to monitor, for example, the sign-up flow, meaning Apica is doing the same actions as a user who would like to sign up, we have been able to figure out when there's a failure in that flow, before it starts to impact users and prevent them from signing up through the services. This is something that has a very high revenue-impact on our company. Apica has helped us find issues with the sign-up before users have started to call customer care regarding the services.

The fact that the solution offers multiple deployment options — on-premise, hybrid, managed cloud solution, bring-your-own-cloud — helps our organization meet our security requirements. Some of the tools in our company can only be accessed internally. To have an internal, on-premise agent makes it easier to test these corporate tools. We have these tools also monitored with the on-premise installation. It helps us to monitor both customer tools, services, and applications, and the corporate tools and applications.

We use the solution’s ability to make use of our own scripts in Selenium and Postman. We're using Selenium to write scripts that can be run for the browser checks, and we're using Postman to run the ZebraTester scripts. Using the scripting feature saves us on resources. It is one of the things that makes the product easy to use. We don't need a specific type of engineer or operator to be able to write these scripts. There are many people who can do the scripting.

In terms of the alerting, since we started using Selenium, which is for the browser checks feature, about 95 percent of the alerts have been real issues. This level of alerting accuracy has saved us time. It helps us to identify root cause quicker. We used to spend something like an hour just to find the root cause, but the ability to have sensitive monitoring reduces it by half. We can identify root cause within 15 to 30 minutes.

Apica has saved us management costs as well. I'm not involved on the financial side, so I can't put a number to it, but I know that we resolve priority-one incidents faster.

We mainly use the ZebraTester and the browser checks. These are the most important scripts that we're using on Apica. 

With the ZebraTester, the ability to have and store dynamic variables, when setting up the monitors, means you can extract that value and use it in a subsequent service call. This is something that has made our lives easier. The most complex monitoring processes are for security purposes: You need to have a fresh token for the user when, for example, he tries to log in. That token keeps changing. To be able to get the results of other service calls that are depending on the login, you need to use that token in the subsequent service calls. Being able to extract that token, store it in a variable, and use it in the other service calls is one of the most complex things. This is one of the features that I like the most because it helps us in configuring these services, in a certain flow, without the need to re-record the whole thing. Being able to extract that value from the service calls is something that has made monitoring a lot easier.

For the browser checks, the screenshots that are available help the engineer or the operator who is on the shift figure out what's wrong or what step is failing.

Also, the flexibility of the solution in terms of the range of protocols it can monitor has been great. The product has been working as expected and it has helped us to cover something like 95 percent of the outages or issues that we have had.

There is room for improvement with the GUI. It's not a big deal, but it would be great to fix the way the GUI is loading. Sometimes when we want the manager alerts and manager checks, it takes time to load all the way. With the whole GUI, if the information appeared quicker, loaded faster than it does now, it would be great.

Also, when it comes to the way the internal agent is installed, because you can install an application on a server, I would love to see the application Docker-ized. If you could install internal agents using Docker or using containers, it would be easier for us to manage them and spin up internal agents. Most of the applications we have now tend to be Docker-ized applications. I'd love to see Apica going that way with its internal agents.

I have been using Apica Synthetic for about five years.

It's stable. Sometimes there's an outage, but it's not frequent.

They offer scalability.

We have about 25 users of Apica Synthetic, people who log in to the tool. About 14 out of the 25 users are engineers with the NOC team and the rest are senior management and engineering leads. We're using the dashboards for management to see the SLAs and the availability of the different websites.

At this point it's being used very extensively. We may increase the number of users in the future, as we have some new projects coming out.

Technical support is always there to answer my questions. They are very responsive. Typically, they all have the ability to support the product, whether it's updates, or issues that we have regarding scripting, or setting it up.

They're just 100 percent available. They always help us on any issues that we have.

We were using Keynote before. I was not involved in the reasons for the switch.

The initial setup was pretty straightforward. There aren't too many requirements in setting up Synthetic. The guides they provided are easy to read and easy to follow. 

Apica support was also always available so we could just shoot a question to them and they would answer right away. During my shift, when I reached out to them via email or a form, they would be able to jump up on a Zoom or a Slack call, to help us right away. They were very helpful. We switched to Apica from a different product and they definitely helped us with recording the scripts that we already had, and with introducing newer ones. They helped reduce the time that we would have had to spend going over the admin guides. Initially, we just wanted to record our existing scripts and they offered to record them. Their support took care of converting the scripts from the language that we used in our old tools to Apica. That saved us time. 

They anticipated our needs during the deployment. They had pretty much everything that we needed when we initially set it up. And when we had a feature request or some kind of additional setup, they tried to provide that feature or help us with a workaround to meet our requirements, even if the product at that point did not have those things directly.

Our deployment, overall, took two to three months.

We had a deployment plan. There was a project manager, and I was involved in writing the scripts and trying to figure out how to convert from the old solution to Apica. Afterwards, I just took care of just recording the new scripts, but there was a whole project for changing to Apica. For deployment and maintenance there were two people involved from our team.

I have not tried all the synthetic monitoring tools out there, but I have tried two of them. They had the same ability to assign the dynamic variables, which is the most complicated stuff that we're implementing, the dynamic variables from one service call to another. But I found Apica offers the easiest way to set this up. This is something that made us stick with Apica, because it's easier to set up the scripts, even with the most complex feature. The two other products I tried have that ability, but it was so complex to set it up. That's what makes Apica better than the others.

Every time I face an issue and reach out to the support, they point me to a part of the documentation. So read the administration guide or the documentation, because they have everything that you need in their Knowledge Base. This is something I learned from opening multiple tickets. It's there in the documents. It now saves me time when I read the documentation.

Apica Synthetic is one of the most important monitoring tools that we're using. 

I would rate it at 10 out of 10 because it's accurate. I've dealt with so many tools and applications, but their support is the most responsive support I've seen. The tool itself offers so many integrations with other applications. It's easy to set up, easy to configure. The documentation is great. The most important part is that the tool covered most of the issues we have and was able to help reduce the time that we needed to resolve the issues and the outages that we had.

I used the solution in my last project for performance testing to push the load. It is a load generator tool. It is a cluster-based application. When we have to push a lot of loads, we need not worry about the instance count and how it will be handled. If the load generator engine is across the world, we can populate the load based on the region. We can push loads from specific regions.

The solution captures all our requests and responses. For example, if I execute a flow and capture multiple APIs, the product will capture all the APIs and get us a payload. It is easy to find out where I need the parameterization and correlation. With JMeter, I need to maintain the files and record the sessions. ZebraTester is easier. We do the flow and capture it. We can take it up whenever we want. Saving the scripts is also easy. Capturing sessions is a good feature. The entire sessions are saved. I can easily find the details I need.

We use ZebraTester to build scripts. ZebraTester is a bit complicated compared to LoadRunner’s VuGen. Initially, parameterization and correlation activity are somewhat difficult to do with a new tool. Once we get used to it, it's easy to build the scripts. The tool does not provide automatic correlation features. However, LoadRunner does. It finds out the dynamic values in the script and helps us to do the auto-correlation. It would be helpful if Apica could provide such features.

I have been using the solution for two years.

I used to face issues with the scripting parameters. I contacted Apica’s team members, and they helped me resolve the issue. The product is not much user friendly compared to other tools. There are not many articles on Google. Usually, when we face issues, we find the answer on Google. However, with Apica, it is really tough. Apica provides some documentation that gives us an idea of how to proceed, but sometimes, we cannot find the solution for lags. We have to reach out to Apica’s team to find a solution. I rate the stability a five to six out of ten.

The biggest advantage of Apica is that it is completely cluster-based. I need not worry about the number of users. It’s completely cloud-based. Even if I add more users, it will scale up automatically. Apica’s team will handle it. I do not have to worry about the machines. I rate the scalability a ten out of ten.

The technical team is really good. The support personnel are approachable. We can reach them easily. They spend a substantial amount of time resolving our issues. I have connected with them around four times for script issues. They are good to interact with and take time to explain even simple questions.

Positive

The product is deployed on the cloud. If I have three different scripts, I must upload them, align the user, and select the cluster. The initial setup is a bit complicated. The vendor has come up with some new scenarios. I can upload the scripts and create scenarios like in LoadRunner. I can trigger the test with one click. When we have different types of load testing, like step scaling or scalability tests, it is easy to create scenarios in Apica.

With Apica, we must ensure whether the cluster is available or not. If it is not available, the entire scenario will drop. It is a disadvantage. Once everything is available, creating scenarios and integrating them is easy. It will take a few minutes to set up and execute. The setup is pretty straightforward.

The product is less expensive compared to LoadRunner.

LoadRunner and JMeter are the tool’s competitors. Apica can push a lot of load compared to LoadRunner and JMeter. Apica is sufficient for my application. LoadRunner provides a grouping method.

I will recommend the tool to others. Apica is good for API testing. It is suitable for performing extreme stress tests on applications. If we want to play around with the load and do performance testing, Apica is the perfect solution. Overall, I rate the tool an eight out of ten.

I've used Apica for an insurance project. I've recorded scripts and verified responses from requirement gathering to providing additional data. I also used end-to-end scripting and the LoadTest portal for execution.

The GUI is powerful and doesn't require scripting or regular expressions. It has a vast finder for correlation, which is easier than other tools like JMeter and LoadRunner. It's also easy to integrate with other tools with a separate execution environment. The tool is also easy to use. 

We're performing various types of test execution, including load testing, scalability testing, and end-user testing. End-user testing usually takes around eight hours. We can schedule the tests in Apica. 

I have noticed that the tool isn't widely recognized outside our organization. Also, there aren't any tutorials or dedicated resources for this tool, making it challenging for newcomers to learn. It would be beneficial if someone experienced with it could provide guidance.

Without proper support, it's hard to utilize its capabilities fully. I've found it's not widely used beyond our organization. Despite my experience with similar tools, I couldn't find any mention of it elsewhere when exploring opportunities for my project. 

I believe it has the potential to be a widely used tool, especially when compared to other performance-testing solutions like LoadRunner and JMeter. Here, the results are more precise, and the execution process is straightforward.

I have been using the product for two and a half years. 

I rate the tool's scalability a six out of ten. Currently, only one account in our organization uses Apica for testing purposes.

Unlike other platforms like LoadRunner and JMeter, where you can find answers online, with Apica, you have to rely solely on their technical team. However, their availability is based on US timings, which can be inconvenient for us working in Indian timings. So, we often have to wait for their response, which can be time-consuming. 

Neutral

Installation is straightforward since the tool is readily available and doesn't need knowledge of Java or other programming languages. The tool's deployment depends on the tests. 

The tool is completely free and open source. I've been using it for about two and a half years and installed it on both my personal and client machines without needing a license. All features are available for use without any hidden fees.

I rate the overall product a six out of ten. 

Apica is used to perform availability checks of our IT services. We put what we call synthetic checks in place, and these are mainly used to check if a specific application is running correctly, or if it is not available.

Because it is a platform that allows us to check the availability of our services, we have a process in our company that allows us to open an incident when we receive an alert that is raised by Apica. It is really critical in our company to have a tool like Apica, because every time we have an alert we know that there's a real problem in our system and we can forward the problem to our internal team so that they can take charge of the problem and solve it as soon as possible.

We are very satisfied with the flexibility that is offered by Apica. In our opinion it is much greater than in other products, even more expensive products. We found a good balance between the cost, after our spending review, and the features that it offers. The alerting is very reactive as well as very accurate. We are really confident in the alerts that we receive from Apica. The alerting accuracy has absolutely saved us time because we can minimize false positives and that means that we don't have to spend the time dealing with them. On a monthly basis it is saving us about 20 hours of work. That is the amount of work we did on false positives that we received before adopting Apica. That might seem like a low number, but trust me, when we have a critical issue, 24 hours are a lot.

We decided to move from another provider to Apica because it offers, from our perspective, more features and more advanced use case coverage. For example, it has a feature that allows us to set up business logic on the availability of our services. We can apply multiple criteria to trigger an alert. We have availability checks that allow us to check two different services at the same time and, to trigger an alert, both of them have to be down. One of the very difficult things with this kind of product is the possibility of false positives. Thanks to the flexibility that Apica provides, we are able to minimize the false positives, and that means that when we take charge of a problem opened by Apica, we are very confident that it is a real problem.

We are also using some JMeter scripts. At the moment, the platform itself is not using JMeter scripts, but they provide a converter that allows you to convert a Jmeter script into another language called ZebraTester. Thanks to that, we are using our JMeter scripts without any problems. And that means we can implement automation in the scripting and, obviously, that adds up to spending less time and effort on these automated activities. It's quite critical to have a tool that provides you this kind of automation. Apica also provides public APIs that allow us to run these kinds of scripts on demand. That is a good thing when you have to develop some automation to achieve very specific needs and tasks that are very frequently executed.

Overall, Apica has definitely saved us costs involved in managing monitoring, although I can't put a number on it.

There are several features that are really good. The first one is the flexibility and the advanced configuration that Apica offers when it comes to configuring synthetic checks. It provides the ability to customize how the check should be performed and it is very flexible in the number of synthetic locations that it can use. It allows us to run scripts from different locations all over the world, and they have a really good number of these locations.

There is also the ease of use. The user interface it provides is really advanced, but at the same time, it is really easy to use. That's a really good feature when it comes to daily use and our daily processes on the platform.

It is also very good in terms of the range of protocols it can monitor. Even if, at the moment, we are only using the HTTP protocol and browser synthetic checks—it's mainly the emulation of the end user browser—they also provide other protocols, such as DNS verification.

The first thing that I would suggest they improve is the user interface. Not from the point of view of how to access the features, but how they are presented. The user interface is very clear, but there are some components of the user interface that are not up to date. Just to give you an idea, today we have web applications that are called single-page applications that are much faster than the old style of web application. If we can move faster into the flow of the graphic user interface, and in a more effective way, it will save us a lot of time.

Another feature they can improve is related to how easy it is to set up what they call on-premises locations. Apica offers locations all over the world, but they also offer a manual to install a location on-premises to check the availability of services that are not public. This process, at the moment, is not so easy to achieve. The last time we did it, we were forced to contact their support to set it up. The automation of this kind of setup is not good. It should be something that does not require human involvement to follow the deployment. The possibility of being totally independent in installing and using an on-premises location would be much better.

I've been using Apica Synthetic for about one year.

The stability is absolutely excellent. We haven't had any issues so far. And when there was some kind of unavailability of the service, because no software is perfect, they advised us before or, if not before, as soon as possible, to let us know about the problem. This is definitely a good approach since if you tell us the platform is under maintenance for a problem, we can change our internal processes to take the unavailability into account.

It's very flexible in terms of scalability. At the moment we have about 2,000 scripts running on the platform without any problem. It's absolutely critical, since we are quite a big company, and moving from a software that is quite famous—because CA Technologies is a famous vendor—to another vendor, Apica, that is smaller, could be a risk. But after the PoC, we really trusted the Apica product. We are very happy that the platform is reliable and very scalable.

We used CA Nimsoft Monitor and Dynatrace Synthetic.

We were migrating from another product to Apica, so the main task that we performed was to migrate all the scripts that we were using on the old platform to the new one. We were able to do that thanks to the professional services support that Apica provided us. They offered us exceptional help in performing this task. It was mostly implemented using the APIs that Apica offers, since migrating data from a platform to another one requires some automation. You couldn't think about doing it manually. The Apica platform was made ready for our use cases because they provided the API that we needed to perform the migration.

The second task that I performed internally was to let the company know about the new processes to be implemented using Apica. The technology is the "engine," but then you need to build the "car" around the engine. That meant we needed to develop processes to let the people who were interested in using the platform know how to do so.

In summary, the first technical task was to migrate all the scripts from the old solution to the new one and the second step was to develop new processes, based on how Apica works.

Overall, our deployment took one year. But the level of support we received from Apica during our deployment helped reduce the time and costs involved in switching to their product. Without them, it would have taken double the time. Thanks to them, the time needed was reduced by a factor of half. They anticipated our needs, meaning that every time we asked them something specific, they replied right away, "We can do that. Don't worry."

It's not possible to provide ROI numbers for a simple reason. Last year we only performed the migration of the platform from CA to the new platform, so we have only been using Apica officially starting this year. We need more time to collect this kind of number. But the perception that we have after the assessment that we performed at the very beginning, is that it will halve our cost and double the performance of the processes that are related to the adoption of Apica.

We checked the new Dynatrace Synthetic platform. We decided to dismiss that and move to Apica after we performed the PoC, since we found that Apica was much more flexible than Dynatrace Synthetic.

Another main difference between Apica and the other products was the cost. We really thought that the balance in Apica between the features and costs was the best among all the products on which we did a PoC. 

There is also the support and the innovation that they bring. One of the reasons we decided to leave CA and Dynatrace is that they are bigger companies, but they are slower when it comes to solving a problem or when it comes to implementing a feature that we request. Apica is smaller, but being smaller means that you are even more flexible and more available when it comes to solving a problem. For example, Apica provided us with a totally new feature that we requested, before we moved to them. That feature was not in the Apica platform and it was critical for us. In about one month, they were able to develop that specific feature for us.

If you are looking for a product that offers a huge technology modernization, and quick support, you should take Apica into consideration, for sure. It is a small company compared to others, but they are really quick in answering your needs and providing you modern technology. If your company is growing and is looking to add new monitoring that is up to date, I would warmly suggest Apica.

We decided to use the SaaS version because we are trying to change the model of services that we are using in our company. We are trying to minimize the on-premises products because we don't want to be in charge of the management of the infrastructure of things that are on-premises. We are absolutely confident that Apica respects our security needs and that we can use Apica safely.