AdminProduct Team (Admin, Rigor)

My feedback

  1. 3 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)

    I like this idea Barry. It makes it faster to set up tests. However we have some users that setup tests for others, and would have to keep changing that if we defaulted to the current user

    Sounds like we should either have a per-user default, or make it super easy to specify the current user when creating the check. Moving this to “under review”

    AdminProduct Team (Admin, Rigor) commented  · 

    I like this idea Barry. It makes it faster to set up tests. However we have some users that setup tests for others, and would have to keep changing that if we defaulted to the current user

    Sounds like we should either have a per-user default, or make it super easy to specify the current user when creating the check.

  2. 3 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    AdminProduct Team (Admin, Rigor) commented  · 

    Excellent idea Ryan. Thanks for submitting. We are reviewing improvements to the Status Page now and will include this use case.

  3. 1 vote
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)

    Totally agree Raymond. And as we add additional metrics to RBC, such as SpeedIndex, those make sense as well. Starting to collect use cases for improved Status pages UI.

    Just so you know, we currently do this because the status page can show any type of check, and render time is something that is RBC specific. We only some the metrics that all checks have, even if you have only selected RBC checks. This should be improved. Moving to under review.

    AdminProduct Team (Admin, Rigor) commented  · 

    Totally agree Raymond. And as we add additional metrics to RBC, such as SpeedIndex, those make sense as well. Starting to collect use cases for improved Status pages UI.

    Just so you know, we currently do this because the status page can show any type of check, and render time is something that is RBC specific. We only some the metrics that all checks have, even if you have only selected RBC checks. This should be improved. Moving to under review.

  4. 1 vote
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)

    Hey Ryan, thanks for the suggestion.
    We have are currently planning to switch the Benchmark check over to using our RBC platform under the covers to perform the tests. This makes many more metrics available to Benchmark check, include DomContentLoad, Fully Loaded, as well as future things we add to RBC, such as SpeedIndex.

    We email you to better understand what you mean by 3PC Javascript “calls” (the requests to 3rd party urls? The number of function calls 3PC JS makes, etc)

    AdminProduct Team (Admin, Rigor) commented  · 

    Hey Ryan, thanks for the suggestion.
    We have are currently planning to switch the Benchmark check over to using our RBC platform under the covers to perform the tests. This makes many more metrics available to Benchmark check, include DomContentLoad, Fully Loaded, as well as future things we add to RBC, such as SpeedIndex.

    We email you to better understand what you mean by 3PC Javascript "calls" (the <script src> requests to 3rd party urls? The number of function calls 3PC JS makes, etc)

  5. 5 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)

    Totally agree. Our notification system needs to be more flexible in allowing multiple different levels of alerting based on the conditions.

    We are currently gathering use cases for a complete revamp of the notification system. This is a great one to include. Thanks for the suggestion Scott!

    AdminProduct Team (Admin, Rigor) supported this idea  · 
    AdminProduct Team (Admin, Rigor) commented  · 

    Totally agree. Our notification system needs to be more flexible in allowing multiple different levels of alerting based on the conditions.

    We are currently gathering use cases for a complete revamp of the notification system. This is a great one to include. Thanks for the suggestion Scott!

  6. 3 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)

    I know inside the app, we should run-level metrics for a tag set under the “Dashboards”. Makes sense to apply this out to reports as well. Reaching out to Melanie to get some clarifying details.

    AdminProduct Team (Admin, Rigor) commented  · 

    I know inside the app, we should run-level metrics for a tag set under the "Dashboards". Makes sense to apply this out to reports as well. Reaching out to Melanie to get some clarifying details.

  7. 3 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)

    Thanks for writing in William. I totally agree. We should allow specific notification settings to tie to 1 or more threshold monitors.

    We are currently defining use cases for a completely revamped notification system. This seems like a logical one to include. Moving to under review while we plan.

    AdminProduct Team (Admin, Rigor) commented  · 

    Thanks for writing in William. I totally agree. We should allow specific notification settings to tie to 1 or more threshold monitors.

    We are currently defining use cases for a completely revamped notification system. This seems like a logical one to include. Moving to under review while we plan.

  8. 28 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    AdminProduct Team (Admin, Rigor) supported this idea  · 
  9. 54 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)

    Step 1 is adding support for custom user timings, since a selenium scripts walking through a flow on a SPA doesn’t generate multiple HARs it generates 1 HAR.

    We recently upgrade our version of FireFox used by RBC, allowing us to leverage the custom user timings API to collect metrics and then report/graph/alert on them. We are planning our SPA/custom user timings project now

    AdminProduct Team (Admin, Rigor) supported this idea  · 
    AdminProduct Team (Admin, Rigor) commented  · 

    We are adding support for custom user timings to allow Rigor to monitor, trend, and alert on any aspect of a Single Page App beyond the initial page load info.

    AdminProduct Team (Admin, Rigor) commented  · 

    Step 1 is adding support for custom user timings, since a selenium scripts walking through a flow on a SPA doesn't generate multiple HARs it generates 1 HAR.

    We recently upgrade our version of FireFox used by RBC, allowing us to leverage the custom user timings API to collect metrics and then report/graph/alert on them

  10. 3 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    AdminProduct Team (Admin, Rigor) commented  · 

    Love this idea Melanie. A clear, obvious usability win

  11. 6 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)

    This makes total sense. It also adds consistency with our RBC check, which can report metrics about each page visited when running a check that loads multiple URLs

    AdminProduct Team (Admin, Rigor) supported this idea  · 
    AdminProduct Team (Admin, Rigor) commented  · 

    This makes total sense. It also adds consistency with our RBC check, which can report metrics about each page visited when running a check that loads multiple URLs

  12. 8 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    AdminProduct Team (Admin, Rigor) supported this idea  · 
    AdminProduct Team (Admin, Rigor) commented  · 

    We are currently exploring options for monitoring internal systems.

    A work around is to expose these systems to the internet, but to limit access to a specific whitelist of IPs. You can also put them behind a more of HTTP auth on top of restricting IPs to ensure only Rigor can access them.

    We know this is not an ideal solution and are reviewing how to offer a true internal monitoring option

  13. 4 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    AdminProduct Team (Admin, Rigor) commented  · 

    Both Bridgette's initial suggestion and Kathryn's expansion are great ideas. Simple to do, and a clear, obvious UI win

  14. 3 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)

    I really like this idea, thanks Steve. Basically, if multiple checks are all testing different aspects of the thing, and a few “key” checks start failing and sending alerts, you probably don’t want to receive a flood of alerts.

    We are in the currently collecting use cases for a reworking of our entire notification/alerting system. This seems like a good use case to include in our scope

    AdminProduct Team (Admin, Rigor) commented  · 

    I really like this idea, thanks Steve. Basically, if multiple checks are all testing different aspects of the thing, and a few "key" checks start failing and sending alerts, you probably don't want to receive a flood of alerts.

    We are in the currently collecting use cases for a reworking of our entire notification/alerting system. This seems like a good use case to include in our scope

  15. 4 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    AdminProduct Team (Admin, Rigor) commented  · 

    Thanks for submitting the idea Don. This is should be easy to add. Will review with engineering

  16. 4 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    AdminProduct Team (Admin, Rigor) commented  · 

    Thanks for the idea. I can totally see how this would be valuable. We are investigating how to do this in RBC now.

    In the meantime, you can uptime files via the API Check, (By sending a POST withy a multi-part body) which at least can help you validate the functionality of an application flow involving a file upload:

    http://rigor.com/blog/2016/07/announcing-new-api-checks

  17. 8 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    AdminProduct Team (Admin, Rigor) commented  · 

    100% agree Austin. SpeedIndex is a critical metric we should be monitoring. our Engineering team is currently working on this.

  18. 5 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)

    I like this idea. We have the concept of what we call “SLA uptime” which is like uptime, but uptime is only impacted if 2 runs failed in a row, from different locations. Essentially we are trying to take the network between the test location and the target out of the equation. However this is not well exposed in the UI and it not available everywhere. Perhaps that can help address this.

    AdminProduct Team (Admin, Rigor) commented  · 

    I like this idea. We have the concept of what we call "SLA uptime" which is like uptime, but uptime is only impacted if 2 runs failed in a row, from different locations. Essentially we are trying to take the network between the test location and the target out of the equation. However this is not well exposed in the UI and it not available everywhere. Perhaps that can help address this.

  19. 5 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)

    Thanks for the idea! This is actually similar to the “Notify on Check Status Change” idea. Basically, send different people different things under different conditions.

    We are currently collecting use cases for a reworked notification system. This is a good idea to consider.

    AdminProduct Team (Admin, Rigor) commented  · 

    Thanks for the idea! This is actually similar to the "Notify on Check Status Change" idea. Basically, send different people different things under different conditions.

    We are currently collecting use cases for a reworked notification system. This is a good idea to consider.

  20. 6 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)

    The ability to enforce SSL certification verification (aka fail the run if the SSL certificate isn’t valid) is currently in private beta, and will be coming out to the general public by the end of this month (Dec 2016)

    AdminProduct Team (Admin, Rigor) commented  · 

    We are considering bring this to other checks, such as uptime/API Check as well

    AdminProduct Team (Admin, Rigor) commented  · 

    The ability to enforce SSL certification verification (aka fail the run if the SSL certificate isn't valid) is currently in private beta, and will be coming out to the general public by the end of this month (Dec 2016)

Feedback and Knowledge Base