We're excited to announce the open beta release of an impactful update to our HTTP error details: payload and response collection! Front-end elements of this feature are still in development, but we didn't want to wait to give you access to the new functionality. Review the Early Access Conditions to learn how to enable HTTP payloads and responses in your Noibu console.

Feature Overview

Back in January, we released our first version of HTTP Error Details, a feature that collects insights to help developers resolve HTTP issues. To date, these insights have been limited to HTTP header information, but we’re excited to announce the addition of HTTP payload and response data collection.

How does this help your team? Having Noibu store payloads and responses eliminates the need for engineers to set up “log traps” to smoke out bad data as the root cause of an issue. This simplifies the workflow, allowing an engineer to access it in one system instead of having to search across a network of hard drives for the same information.

Payloads and responses will be visible in new sub-tabs in the HTTP Error Details section on the Developer tab.

You can also access payloads and responses in the Session Timeline when the HTTP box is checked. Please note that not all HTTP entries will have event information; events with information are marked with a purple arrow icon. Click on a purple arrow to expand the event’s details.

Early Access Conditions

Collecting HTTP payload and response data may expose personally identifiable information (PII), so Noibu will not enable this feature for all domains by default. Instead, we’re leaving it up to you to identify URLs on which payload and response data collection should be allowed.

We’re working on a new tab in the Domains page where you can configure a list of Allowed URLs for HTTP payload and response data. This page is still in development, but you can get an early start on collecting HTTP payloads and responses by submitting a request to support@noibu.com. The email must include the domain and a list of requested URLs.

When submitting URLs, please follow these guidelines:

• URLs are case-sensitive.
• If you allow a base URL, any sub-URLs will also be permitted for payload and response data collection. Use with caution!
  • Example: /products will include ALL of the following:
    • /products/
    • /products/.*
    • /products/anything
• You can enter a partial/relative URL, like a path or page name, to allow data collection on any URL that includes the fragment. However, relative URLs are only allowed on-domain.
  • Example: /products/add-to-cart
• You can insert a period and asterisk as a wildcard for a dynamic URL.
  • Example: /products/.*/add-to-cart
• URLs can be on or off domain if they are absolute.

In addition, it is important to keep the following in mind:

• The URL(s) you add can be from any first-party or third-party domain. However, payload data will only be captured if an HTTP error is encountered with that URL.
• Captured payload data from any user session will remain available for 7 days after being captured.