In the past year, we have released a number of major new features to Rigor Monitoring and Rigor Optimization. What you may not know is that the majority of these features were driven by suggestions from Rigor users based on their needs. In this post, I want to give you a peek behind the curtain to show how suggestions from Rigor users become the features we rely on every day.

Expanded Scope of Testing

At Rigor, we are always working to expand the scope of both what performance data we can collect, trend, and alert on, as well as what performance defects we can detect bring to your attention. Deciding how to expand that scope is driven by conversations with our users not only about their current needs, but understanding their business needs related to their long term technology roadmaps.

Perhaps the best example of user suggestions leading directly to an expansion of the scope of our monitoring capabilities is Rigor’s API Check which launched in July. For years, Rigor enabled customers to measure, trend, and alert on API performance via our Uptime Checks. As we had conversations with our users we constantly encountered users who were trying to push the limits of what was possible with Rigor Uptime Checks.

We learned that more and more of our users were relying on the need to power mobile apps and microservices. And a growing number of users relied heavily on integrations with third parties which caused our users to adopt more APIs. While users adopted more APIs, the APIs themselves became increasingly sophisticated. As time went by we discovered that many users needed the ability to test complex, multi-step API flows and transactions where data from one API call needed to be extracted, validated, and then reused across subsequent API calls. This feedback directly lead to the creation of new our API check:


We not only used this feedback to scope out the specific features to build into API Check, but we also launched a private beta period for customers who expressed interest in this new check type. Our customers provided valuable suggestions and input that we were able to incorporate to improve API Check before it was launched to the public.

While API Check was a pretty major new solution with a large scope for development, sometimes it’s the little things that can make our app more powerful and easier to use. Here are some smaller scale improvements that we were able to make available based on feedback from our users:

Going with the (work)flow

While increasing the scope of our performance insights is valuable, moving those insights into your existing tools, workflow, or processes is often even more important. Let me share with you a real world example:

Rigor Optimization has had a JIRA integration for several years, but it was cumbersome and built on top of our Share Via Email feature, which required email aliasing.

Talking with our users, we learned that the people using JIRA often weren’t the people who could configure this in Optimization, or the people who could set up the email aliasing required to make this easy. We also learned that customers really needed more control over the ticket that would be created in JIRA. Some optimizations needed to be classified as improvements instead of as bugs. Users also needed to be able to define the project for the JIRA ticket or even associate the ticket with a specific component.

I used this example because Rigor was providing great value to customers because we could detect performance issues. But there was too much friction getting those findings into our our users’ workflows, in this case, too much friction getting data into their defect tracking software so issues could be assigned and addressed. So, while people told us they liked that we had a basic JIRA integration, it wasn’t useful in practice. When we learned this from our users we shipped a native JIRA Integration to Rigor Optimization, allowing you to create JIRA tickets for bugs directly from the Rigor Optimization UI.


Another major customer-driven workflow initiative was the creation of new, versioned APIs for both Rigor Monitoring and Rigor Optimization. While both products had existing APIs, they had grown separately and organically in response to user needs. This resulted in poor documentation, inconsistencies in the API function calls and data structures, and an unevenness in the level of detail available in different parts of the APIs.

Using recurring questions from our users as a reference, we knew that we needed to create an API that was:

  1. Fully documented, including example requests and response data, with a mechanism for users to test the API directly from the documentation.
  2. Versioned, so we could improve the API without impacting our users.
  3. Robust, capable of providing all of the data the user can access via Rigor’s user interface.

Based on these specific requirements, we adopted a Swagger-based API system across both products with a common UI, naming conventions, and documentation structure, as well as the ability to test the API from inside the documentation.


This also forced us into an API-first mindset, so that new features or visualizations in the products are built on top of our API.

For example when we released customized Defect Check Policy for Optimization (a feature that was also driven by user feedback), the ability to change defect severity, threshold, and mute defects are all also available via our API, because that’s what the app itself uses!

We <3 User Feedback

In this article we presented the backstory behind many of the awesome features we have released in the last year, and how those features we all driven be feedback from our customers. Are you a Rigor user? Do you have ideas on ways we can improve the product?

We want to hear from you! Here’s how you can help:

a) Book a call. Use this super fast and easy Calendar link to schedule a time that works for you to speak directly with Rigor Product Management. Tell us what you like and what we can do better. While we’re on the call we’ll share a sneak peak of some of the new features we’re working on now.


b) Post on our Rigor Idea Exchange. See what other users are asking for, vote up suggestions, and share your own requests. When Rigor Engineering picks up a feature for development from the Idea Exchange, everyone who submitted or voted on that suggestion’s post will get an email notification, so this is a great way to stay on top of the development progress of the features that matter most to you.

Suggested Blog Posts

The Perception Gap for Poor Web Performance

E-commerce revenue continues to grow,as consumers turn away from shopping in brick-and-mortar stores to shopping online.  However, many businesses are not prepared for this growth because they do not fully understand the market and how to invest in...

Read More

Measuring Cross-Browser Performance

In recent years, client-side browsers have been more involved with processing code before it reaches the user's desktop, shifting away from a reliance on servers handling the bulk of this burden. Websites and applications now rely more on a user's br...

Read More

Using Browser Trends to Maintain a Better Site

Because of the multifarious nature of web clients today, it’s important to consider the usage statistics when designing, implementing, and managing your site. However, misconceptions often arise when determining what browsers to design for an...

Read More

Finding Causes of Intermittent Errors from Google Webmaster Tools

Google Webmaster Tools is a web service that allows webmasters to view the status of their sites as seen by Google and the Googlebot crawlers. In addition to indexing your site structure and content, the Googlebot crawlers also record data on perform...

Read More