The stability is very good. Almost every time where we've had an outage, it had not been due to the software, rather, it was some element of our infrastructure failing. The most common failure for us is we lose connectivity between the database and the application. There's not an app alive that's not going to have some problems when you can't connect like that.

The stability is the piece of the product that I absolutely love. The core part of the product works extremely well and I'm very comfortable with how it works and how it's designed. We rarely have any serious, production-impacting issues. We probably have at least four nines of uptime and availability.

Our instability issues are more on the other systems that it is connecting to and not Tidal itself. Tidal does what it is supposed to do. We do have timeouts. When Tidal is trying to talk to our JD Edwards system, it times out. And every time we increase the timeout value on the E1 side, it seems to resolve that issue for a little bit. Overall, Tidal itself is pretty reliable, but what it is connecting to is what gives us reliability issues, if we see any.

In fact, we ran across a case where Tidal was too smart for us. It submitted a job and was detecting that the job wasn't acting correctly and kicked out an error, even though the job was actually completing. I took it to the developer and he was able to determine there was a problem with the code. Tidal was responding to that error, but we had never seen that before. I haven't seen any other system work as well Tidal's J.D. Edwards adapter does.

Tidal has been pretty stable. We've had these little quirks, but they are mostly just minor bugs that crop up every once in a while. For instance, you might have to click on something twice or click off of something, like a tab, and then click back on it and it will bring up the screen. But other than that, it's been pretty stable.

It is stable. We don't have any issues with the Enterprise Scheduler. It never goes down.

Very few people are required to maintain and administer Tidal because it is very stable. Right now, we need people to administer it when migrating stuff within Tidal because that need to be done manually. We are a team of four because we are spread across multiple geographic locations, but we do other stuff too. E.g., while I am a Tidal Administrator, we do support other platforms.

It has been great. 

We have only ever had one system outage related to Tidal that was Tidal's fault. That's pretty amazing for a product that we use all the time.

The stability has gotten a lot better. Every time that they level a version up, there are a few months where it is a little rocky, especially because they are trying to make some real changes on the back-end. Sometimes, I'm guilty of being a bit too cutting edge with the patches that I put in place. I have learned to hold back a little and give it a couple of months. Usually by that time, they have worked out the bugs and things are pretty stable. I would say this about any system.

I'm the only one who supports Tidal, then I pull in a dev person. There is usually one person involved with setting up the VMs. However, they have that automated so it is just a request for a standard set of servers. They just push a button and the servers are built. When we get to where there is QA testing, we're usually trying to align that with a lot of other QA testing. Therefore, people are naturally testing the system as they would with any other work that they are doing. Essentially, this is all of our schedulers, which are 15 to 20 consistently. I'm not asking them to do anything that they are not already doing, except tell me if there are problems.

I have a very loose backup person but I'm very motivated not to get calls on the weekends or vacation, which is why we built in our alerting systems. We try to keep them strong, so before anything gets to me, it's been vetted by the people who can solve the problem if it is job-specific. If Tidal itself goes down though, I'm the one who gets called because I'm the one who can fix it.

After the 6.2 release, the stability became awesome. With 6.6.1 it was a little bit difficult, but everything after that has been solid.

It is very stable, fortunately. 

The product is highly stable and will remain stable in the long run.

It's been rock solid for us. We've had it for 15 years and I have really never had to make support calls to either Cisco or Tidal. The only times I ever really have to contact them are when we do our renewals or we migrate to a new version and we have to get a different license key.

The stability is excellent. There are days we don't even log into the product because it just continues to run seamlessly.

The basics have always been strong. What is useful for most people, the addition of cloud support and different applications which can use adapters. That comes into play. The ability to interface with Internet functions makes it a pretty strong tool.

Deployment and maintenance depends on the size of the organization. One or two people are probably need, but it can even be a part-time function. The roles of these people also depend. Companies can set up administrator type work, which is to set up the environment, providing the care and feeding of it, such as adding new agents or new users. They are just overseeing the day-to-day maintenance and running of it. There is not much activity with that. Then, there is creating jobs, which is sort of the application side. This is usually the monitoring side where somebody is watching the actual status of jobs and responding to failures or other alerts.

I rate the product’s stability a seven out of ten.

The solution has good overall stability to sustain and process for the long run.

It has been super stable. There are no complaints on stability. We would not be using it if Tidal wasn't stable. You can't have an automation system that is unstable because it is too critical. If it's fallen over, everything is delayed in the morning. The business impact will be significant, because potentially your front office can't trade. If your automation platform doesn't work, you're in bad shape.

Two people are required maintenance.

The stability has been fine.

In fact, we're going back to using the master and the fault monitor. We had it disabled for some time, but we've gone back to setting it up with the fault monitor and the master, and the backup. There was a problem with it. There was some kind of a fault status that kept getting triggered. The network person who was in charge convinced us to disable the redundancy that we had set up, and we've just recently gone back to it. And it's been working fine.

In version 6.5, it is very stable and works quickly. The UI works quickly too. Their services load pretty fast. If one of the servers reboot, they have a layout of the high availability. This means that from each component of the product you have two items. If one of them goes down, then the other one kicks in and starts to work. I really like that idea.

In terms of room for improvement, if one of the master goes down, then another one takes a minute to start. While it is not a big deal, when you commit on four nines, one minute is huge. So, I'm pushing the vendor all the time to be better on this.

They still haven't implemented the load balancing-oriented thinking. So, if I have two client managers, I cannot put them behind a load balancer. Or, I can put them there, but the load balancer will never have a health check. That is something that everyone is doing, building health checks, and they don't have health checks on clients for load balancing. Maybe this will come in the future. I submitted a request for having a health check for load balancers.

In version 6.2, they had a lot of problems. One of the problems is the Oracle support. We are using Oracle RAC and high availability on Oracle. If one of the databases would suddenly goes down, the entire system would crash. In version 6.5, we have tested this. They have done significant work and it's working perfectly. It's not crashing and working continuously without any issues. From this perspective, I am very happy with the new version.

I'm really confident in the stability.

Cisco owned the company for a few years and I felt that it was something of an afterthought for them; it wasn't really their business. They didn't really put the time and effort into it. It seemed like, for a couple of years, nothing was getting resolved and people were pretty unhappy. We ended up staying in a version that was years and years old, compared to what we should have been on because we were not confident in the solution that they were providing, to give us what we needed. 

In the past two or three years, since the new company took over, we have much more confidence. People are much happier with the direction that Tidal is going and the features that they're releasing.

In our non-product environment, it is not as stable for us as it is in our production environment. I'm not sure why it is like that.

I came on about four-and-a-half years ago here and Tidal has been really solid. The high-availability and the fault monitoring they use is very good. I can think of twice, in the last four-and-a-half years where we've actually had to failover for one reason or another. And the bottom line was that it wasn't even a Tidal issue; it was something to do with patching. One of the patches from Microsoft was a little funky. From a stability and support standpoint, this is a rock-solid app, in my opinion.

It's very stable, especially for those who utilize what they call Fault Monitor or Fault Tolerance. When we do patching, the jobs, in and of themselves, automatically fail over from our primary to our backup. There might be a slight disconnect in the web UI that the operators use, but that maybe lasts a minute because of the cut-over time. But it picks up all of the backend PIDs, and the jobs just pick up where they left off. From a stability standpoint, this is a really good product.

The stability has been good. We have had the occasional issue here and there, but overall, it has been fine. Obviously, it hasn't been flawless. For the most part, it's been a pretty stable environment.

There is an administrative team at the app layer maintaining it. There is a senior administrator for it, and two other people who cover for the senior administrator, if necessary. At the Unix and database level, there is just one person maintaining it.

Tidal is pretty stable. We haven't had any major issues, at least in the last three years that I've been working here, and especially since we upgraded. We haven't had many major issues, and we do have redundancy, which is great. We have redundancy for the primary master backup master, and fault tolerance. That that helps with keeping things stable. As of mid-year 2020, I am decreasing the product stability from 8 to 6 stars due to the amount of bugs we are constantly facing.

I rate Tidal Automation by Redwood a nine out of ten for stability.

This is a stable tool and we use it extensively.