Your Infrastructure Will Fail

Why you need to monitor your web presence

Jim Cahill
2 min readFeb 7, 2017

The world has changed. We no longer care for individual, identifiable servers that we feed and groom. Long gone are the days of log rotation, package manager cache-clearing, temp space flushing, and OS installations. Today we live in the cloud.

In the not so distant past, when you wanted to launch a website, dynamic or otherwise, you would do one of two things: buy a server and configure it, or ship your code to a hosting company where they would deploy it for you. Today we no longer rely on these pointed practices. Now we deploy and tear down virtual servers on other people’s infrastructure countless times a day. Infrastructure is immutable, and ephemeral. What goes on behind the curtain is obscenely complex, but we don’t need to care about that. All you need to care about is that when you hit an IP associated with your service, something answers. This has been one of the most important and game-changing shifts in technology strategies since the advent of virtualization itself. There is however a catch, it can fail, and it does fail.

Accepting that infrastructure can fail is a huge step for application developers. It’s a shift in how your write applications, and how you build-in fault tolerance. It’s also a shift in how you think about monitoring your application. Where a simple cron script checking a service status used to suffice, you now need external monitoring tools that make sure the entire system, including wherever it actually lives, is up and running. There are countless tools to help you do this, but none are as dead-simple and flexible as Schezzle.

Schezzle was built with one simple purpose, to bring back the BYO test script mentality to website and API monitoring. We don’t force you into a pre-defined mold of what it means to be “up.” You write the logic that says if your service is up, and we’ll execute it (up to once per second) and notify you when it fails. That’s it. If your notion of “up” is a 200 response code, then write that script. If your notion of “up” is a login request followed by 3 more authenticated requests, then write that script. The possibilities are endless when you use our simple API to define your monitors.

Create a free account and try it out today!

--

--

Jim Cahill

Software engineer, dad, wannabe entrepreneur, corporate employee