Monitoring forms without side effects

Whilst we spend a lot of effort and take great pride in the uptime and availability of UX Forms, we also understand that some customers have sophisticated monitoring and alerting tools of their own that they want to use to check their own forms are up and running as expected.

To date, this has been done by customers pointing their monitoring-tool-of-choice at a form’s root url and checking the status code of the response. This is all well and good, and really does prove that everything’s working as expected, but this request is indistinguishable from a regular user — which is where it starts to get complicated.

HTTP result from a HTTP GET request to our demonstration form, without the response body

When a new user comes to the form url, UX Forms:

• creates a new instance of that form behind the scenes
• puts that instance’s id in a browser cookie so thereafter we know which form they’re using
• logs an event

This event is used in the KPIs presented in the dashboard, specifically the completion rate of the form. UX Forms then goes through all of the widgets in the first section of the form, fetches all of their templates from our content server, renders them, and builds up the entire html response to send back to the browser. Whilst all this is done in the blink of an eye, it’s work that is wasted if all the monitoring call cares about is “is my form running?”

Completion Rate: In the given time period, how many forms were started verses how many forms were successfully completed.

Unfortunately, as there is no fool-proof way to reliably distinguish monitoring traffic from “real” traffic, we have to do this every time regardless of the intent of the request. So customers effectively had to choose between monitoring their own forms and having useful completion rate statistics. It’s not ideal for us, either, as we end up with lots of orphan form instances that get created for no reason and have to be cleaned up.

HTTP verbs to the rescue

So, if requesting the form just to see if it’s running isn’t ideal, what should we do instead? It turns out there’s a mechanism in HTTP that has been designed for precisely this:

The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response. […] This method is often used for testing hypertext links for validity, accessibility, and recent modification.
https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

Therefore instead of issuing a HTTP GET against the form and incurring all the overhead that entails, you can now issue a HTTP HEAD against the same url instead. We don’t create a new instance of the form, we don’t count this request in our KPIs, we don’t even have to go to the effort of rendering the form and returning its html, we just return a simple HTTP status code saying whether that form is running OK or not.

HTTP result from a HTTP HEAD request to our demonstration form

Want to know more?

Come have a look around https://uxforms.com, follow UX Forms on twitter, or email us at hello@uxforms.com and see how we can make your forms better, together.