madflojo

hoverfly actually looks very nice. Other projects in this space are either a ton of setup, language specific, or SaaS only. My main motivation was I needed something stupid simple to get up and running in minutes instead of hours.

hoverfly looks a lot easier than most of the more popular solutions out there.

Yeah, thoughts and opinions are my own of course but overall we've had good experiences.

I tried to insert some of the benefits we are seeing into the article in different pieces but now that we are several years later have it running in production. We are happy with the decision. In my opinion, there are even some newer things we didn't write in Go that I kind of wish we did.

The reasons we choose Go are holding true, and I can't say enough about how the performance and low GC times out of the box is something that is very beneficial. At least for my use cases.

All good. There were a lot of factors to creating the list, Enterprise use and readiness was one big one. So we narrowed it down to what we thought were the best choices. Always the possibility we missed something, but thats true of any decision like this.

Appreciate the read and questions though!

I'm not an expert in Rust or dotNet Core but I can give a bit of insight. At the time (2016) Rust wasn't as visibly used in production as it is today. Also from my understanding over the past few years a lot of new features have gone into Rust which makes it more viable these days.

As far as dotNet Core, it is used at AXP but generally not in our high performance environments. Not saying it couldn't as I'd have to do a lot more research to say one way or another on that. But I'd say that's the primary reason it wasn't added to the list.

Can't say enough about how I feel about Assembly. It's such a great way to launch that idea you had but never got started.

Thanks for the thoughts, I'll have to think pretty heavily on the pay-only service. There are many companies out there that have done well with a try before you buy model.

You make a valid point with the fact that we have already open sourced our product so a free tier is giving away even more.

> Companies pay ridiculous amounts for things as trivial as chatrooms, so if you're automating away DevOps/System-Administration, you can charge a decent chunk of change that will come cheaper than say $4,000 per month for a senior system administrator.

So very true. I guess when you put it that way $1 per monitor is a pretty low price and I think you're right we may just be going too cheap and labeling ourselves wrong.

> To me it seems like an automatic server-monitoring service that detects and tries to fix errors.

Yup, that is exactly what it is.

Thats good advice though one part confused me. Are you saying our pro package is too cheap or too expensive?

Right now the main difference between our pro and free accounts is the number of monitors available. With free you can only have 2 whereas with pro there is no limit except that each monitor costs.

Ok so you would be fine with 9.99 a monitor but more likely to buy if it was in a tiered package. Thanks!

Thanks, that helps a ton with a future direction where our monitors are server based. What we have right now is all external monitors. Think along the lines of Pingdom but a lot more types of monitors.

Thats fair, I'll make sure we add at least screenshots in the future.

Right now we don't have any demo, but you can sign up and if you like it you can choose to upgrade. Upgrade gives you more monitors and more intervals but everything else is the same between free and non-free accounts.

That is some good feedback, we have a bounty open to revise the "responsiveness" of our site. To make it work a bit better cross platform. We move pretty fast I doubt it would take us very long to have that fixed up.

All interesting projects with their own twist on it. The space we are aiming to hit can be equated to IFTTT + Nagios.

True, that is something worth looking into. We are also of course looking at setting up some Docker images for quick and speedy deployments.

Hey jprince, I'd have to look at the "Not Idle" monitors for dynos that don't exist. The way that monitor works is it looks at the monitor status to see if any are idle, if there are no dynos then there would be none idle.

The UI is also something that we are working on, in fact it is our next big project. We are a growing app so some things aren't exactly perfect but were working towards it.

Also if you wanted to stand up your own instance you could follow this.

http://runbook.readthedocs.org/en/master/developers/install/

It's geared more towards a development environment for the reasons I mentioned above but it would get you a running instance for sure.

Thats a good point, right now we work solely off of API's and don't offer any way for us to store usersnames/passwords. The thought is that API credentials can be revoked easier. In general we are looking to meet the market of folks who are 100% in cloud environments, where the adoption of a SaaS solution is not as much of a concern. But in the future there are some ideas on how to handle self hosting and not sending credentials to the SaaS environment.

But we are open source, and our license does allow for self hosting: https://github.com/asm-products/cloudroutes-service/blob/mas...

At the moment we are taking a very IFTTT style approach where we have monitors that are external facing that can test things like TCP ports, HTTP status codes and anything we can get at with a webhook or API (i.e. Datadog, Papertrail, Heroku). When we resolve things it is all via external services that we can integrate with via API's or webhooks (Commando, DigitalOcean, Rackspace, AWS and so on).

On our roadmap is building an agent (and there is a wrapper for our webhooks), this would allow us to run monitors and reactions locally on the server itself. Where we would shine over a tool like Monit is that once we have an agent you could define that reaction to happen on any server.

So for example if we detected a database error using a keyword search on the web app. You would be able to execute commands to fix it on whatever servers you define.

So think of it like, being able to run the actions across as many servers as you want.

Hi, We are an assembly product so there is a link to our Assembly page: https://assembly.com/runbook which is where we lead the development and you can find a link to our repo. Also: https://github.com/asm-products/cloudroutes-service we just changed our name from CloudRoutes to Runbook so forgive any old references.