Ever encountered an error in your application that really scared you? An error that raised your heart rate and sent adrenaline surging through your veins? If so, you’re not alone. This happens to all of us eventually. I’d like to share a story with you that shows how you can stay calm and sharp during such a crisis with a little help from Ruxit, our web monitoring tool.

Although you couldn’t tell by looking at it, our sign-up process has undergone several revisions since we first released it. We had issues with customers being unable to complete the signup process because of JavaScript failures during signup. Even with the most reliable deployment chains in place, things can still break. Conditions may be suboptimal, files are lost, and you end up with corrupt or incomplete builds.

With this in mind, we developed an alternative approach to signup. Now, rather than relying exclusively on JavaScript for signup, we offer a JavaScript-free means of signup in the truest sense of progressive enhancement. The new approach guarantees the functionality while adding extended behaviour and UX through JavaScript. With this approach we ensure that if anything should break in our JavaScript, new customers will still be able to sign up.

Ironically, as soon as we released our new “failsafe” signup process, errors began to pile up and we had to take advantage of the progressive JavaScript enhancements we’d built in.

Real user monitoring for error detection

As soon as we deployed the new signup process we began receiving Ruxit problem alerts. In fact, Ruxit reported a 100% error increase! On every page of our site!

Failure rate increase

A quick look at the root cause analysis provided by Ruxit showed us the culprit: We were asynchronously loading a PHP file for the signup script that wasn’t available:

Quoth the server: 404

Receiving a 404 status code on an important part of our sign-up process was definitely a severe error! Immediate action was required!

We were stressed about our options and fearful we might make a bad decision. Consider our options: we could roll back to a previous version of our application that didn’t include the new signup process. Or, we could rebuild the entire application and ensure that all the files were uploaded correctly.

Meet your wingmen: web checks

Luckily, we had Ruxit availability monitoring to give us some direction. We had a web check running, executing the signup process every 10 minutes from 10 different locations around the world. We learned that even without the output of the missing PHP file, we were still completing every synthetic signup triggered by our web check.

Ruxit web checks

So, while we still had a critical error to address immediately, reported accurately via Ruxit real user monitoring, we were relieved by what we learned from our web checks: despite the errors, users will still able to complete the signup process. No real users were affected, and thankfully, our fallback plan worked as intended! After this discovery we were able to calmly focus on addressing the missing PHP file error. We found a workable solution that we then deployed in less than half an hour.