Runscope API Monitoring    Learn More →

Posts filtered by category: debugging

How to Monitor Live Production API Traffic with Runscope Traffic Gateways and Alerts

By Neil Mansilla on .

Runscope started off several years back as an API debugging tool that allowed developers to inspect in-flight API traffic and debug integration issues. Even as our product evolved to include comprehensive API testing and performance monitoring, we’ve always stayed true to our original mission of helping our customers not just detect API problems, but also solve them. With our latest release of Live Traffic Alerts, we provide our customers with a new layer for API problem-solving—catching key API transaction errors with live production traffic monitoring. By notifying your team about failed API calls in near real-time, your team can respond and remediate issues quickly.

Many businesses can be deeply affected by errors or anomalies that occur in production and cannot be simulated with traditional functional monitoring. Some of these scenarios include catching declined credit card payments or...

Read More →

Categories: webinar, product, monitoring, howto, debugging

Introducing Runscope Live Traffic Alerts: Catch Failed & Exceptional API Transactions with Real-Time API Monitoring

By Neil Mansilla on .

Even the most well-written software with a comprehensive test suite is susceptible to seemingly random, intermittent failures and exceptions while running in production. If your software relies on or integrates with internal or external web service APIs, the possibility for encountering exceptions is compounded due to many factors beyond your control, such as poor network connectivity or the API itself being broken.

Many businesses, such as retailers, mobile app developers, media providers, data brokers and infrastructure providers, rely on APIs to meet the demands of their customers across a plethora of platforms—web, mobile and IoT to name a few. Poorly performing APIs have a significant impact on revenue, engagement and other success metrics, yet many of those API transactions occur only in the wild and cannot be simulated. Detecting API call failures and anomalies—like a credit card payment failing—is a vital component to a layered monitoring approach.

Runscope already offers a suite of tools that allow thousands of DevOps, QA and development teams to proactively monitor the APIs they rely on most. Today, we're excited to announce the addition of real-time API monitoring with Live Traffic Alerts. This unique combination of uptime monitoring and functional testing with real-traffic monitoring gives development teams a complete performance picture into mission-critical APIs throughout the entire API lifecycle. 

Now Available: Runscope Live Traffic Alerts

Runscope Live Traffic Alerts logs live API traffic and notifies developers when key API transaction failures and exceptions are detected in near real-time. With Live Traffic Alerts, developers can detect specific API call failures that can only be observed in production, reducing time to resolution and minimizing lost revenue from breakages—all without ever having to write a single line of code.

These exceptional API calls include:

  • Creating leads in a CRM platform
  • Charging customer credit cards via payment APIs
  • Facilitating marketplace transactions using a supplier's API
  • Registering a new user to a database

Leveraging Live Traffic Alerts can help you not only discover hard API failures, but also more nuanced issues like intermittent or gradual increases in network performance degradation. Alerts can be configured to inspect and compare values within the response payload. For example, you can set an alert to monitor inventory or sales falling below a certain level.

Live Traffic Alerts allows you to: 

  • Generate notifications when important API calls fail (e.g. payment APIs)
  • Keep tabs on slow endpoints
  • Verify SLAs
  • Catch erroneous API calls so that you can retry them
  • Create custom performance dashboards

Get Started with Live Traffic Alerts

Setting up Live Traffic Alerts is simple. Sign in to your Runscope account (sign up here if you do not have an account), and navigate to Alerts at the top of the dashboard. In the animated screenshot below, we're creating an alert that detects failed API calls to our credit card payment provider.

You can add multiple rules per alert (up to 10). In the example above, we only examined the status code of the API response; however, rules can be based on the following sources of data with various comparison operators:

  • Request (form and URL parameters, headers, body, URL)
  • Response (headers, body, status code, response time, response size)
  • Connection (source IP, destination IP, connection error, service region)

Collecting API Traffic

Live Traffic Alerts evaluate against all API calls stored in each respective Runscope bucket. API call traffic can be collected in your bucket via the following channels:

In the next example, we use the Global Traffic Gateway (i.e. Gateway URL) method. For instance, if we wanted to collect and monitor API call traffic between our mobile app and a third-party API, we would just modify the original API's base URL to the transformed Runscope Gateway URL. The network overhead for passing through the Runscope Gateway URL is very low. Runscope leverages intelligent geo-based routing, sending the API call to the Runscope Service Region closest to your client application.

To generate a Runscope Gateway URL, click on the Create Gateway URL button from the Alerts menu. On the pop-up form, we'll type in the URL of the API we're calling from our app. Below that text field, a Gateway URL will appear, and that is the URL we'll use in our apps to make API calls.

When we enter a URL, it is transformed into a Runscope Gateway URL. Dots are transformed to dashes. The bucket key (unique identifier for our bucket) is appended along with the domain and path for the request. Using the Gateway URL Helper is not mandatory (you can construct Gateway URLs yourself by following the transformation rules).

Additionally, there are several language-specific libraries that automatically create or magically route traffic to Runscope Gateway URLs, including Java/Android, C#/.NET, Go, JavaScript, Objective-C/iOS, PHP, Python and Ruby.

As traffic is flowing into the bucket, when a failed payment API transaction is detected an alert is raised. Each subsequent 504 match will increase the match counter. When we Acknowledge the alert, the name of the acknowledger is logged, and the counter is reset. If we had any notifications configured (e.g. Slack, HipChat, Flowdock), alert notifications are sent on the 1st, 10th, 100th and 1,000th alert.

Start Monitoring Key API Transactions Today

We recommend that you begin by monitoring your key transactional APIs—those mission-critical calls that when they fail, can result in lost revenues or require extensive time to remediate (i.e. payments API, new user registrations, important transactional emails, etc.) For clarification, you can use the Global URL Gateway on any cloud accessible API, including third-party platforms—not just the services you own and operate. 

Runscope Live Traffic Alerts is now available for all Medium and larger accounts, as well as those on the free trial. Sign up for Runscope today to get started using Live Traffic Alerts. If you're currently on a Free or Small plan, contact our Support team for a trial of Alerts. For more information, read the documentation or email

Free Webinar and Live Demo to Learn More

There is so much you can do with Live Traffic Alerts, and using Alerts in concert with the rest of the Runscope suite of API monitoring and testing tools provides a complete performance picture into your mission-critical APIs throughout the entire lifecycle. Learn more about how you can benefit from a layered monitoring approach that includes both proactive and real-time monitoring in our free live webinar on Thursday, October 29 at 10 a.m. PT. Reserve your spot, and if you can't make it, we'll send you the recording. For an in-depth look at Live Traffic Alerts, join us for a live demo of Live Traffic Alerts on Tuesday, November 3 at 10 a.m. PT.

Categories: announcements, debugging, monitoring, product

Use Runscope for Advanced Error Logging

By Darrel Miller on .

Supporting web APIs can open a labyrinth of issues you need to proactively manage. It can be tricky finding easy ways to get notified about problems before your customers encounter errors. Plus, time is always of the essence, and infrastructure to capture errors isn’t always readily available. Fortunately, Runscope has a quick and easy way to log your HTTP error data for greater visibility so you can fix problems fast, in just a few steps.

Logging failed HTTP requests and responses provides a complete picture of the failed interaction. HTTP requests are designed to be stateless and self-descriptive, so everything you need to know about the intent of the client is captured in the request. There is no other transient context that gets lost. So tracking down the source of an error is much easier than when dealing with complex stateful interactions. Below, we take you through the steps to integrating with the Runscope API to log this data in your Runscope instance.

Integrating with the Runscope API

By using the Runscope API and a small piece of middleware in your Web API, you can push failed requests into a Runscope bucket. Logging in to the Runscope Dashboard allows you to see the failed requests. To close the loop, use Runscope’s notification integrations with services like Slack and PagerDuty to notify you when an error occurs, and create some API tests to check if new errors appeared.

Creating new requests via the Runscope API is fairly straightforward and most web platforms have infrastructure for inserting middleware into the request response pipeline. In Python there is WSGI, Ruby has Rack, Node.js has Express Middleware.

.Net Implementation

If you happen to be in the .Net space, life is even easier because I have already built the middleware component to do the hard work. Simply install the nuget package, and then add the following code to your API configuration.

You can create a new API Key by following the instructions in this screencast. The Bucket Key appears in the bottom left corner of the dashboard on the Runscope Traffic Inspector page.

The third parameter is a filter function that determines which bucket to use to record the request and response. Returning a null bucket indicates that we don’t want to store the request. This example simply stores all 4XX or 5XX into a bucket. However, that function can be as clever as you like. The source for this project is available on Github.

Centralized Logging

An interesting benefit of this approach to error logging is that if you have multiple HTTP APIs, either internal or external, you can configure each API to post errors to the same Runscope bucket. If you get into a situation where there are cascading failures of requests between APIs then you can easily see which API failed first and the impact of that failure.

It’s easy to log HTTP errors with Runscope, and even easier to get started. Sign up for free today.

Categories: product, howto, debugging

Crash Avoidance: Stay Ahead of API Problems with API Performance Metrics and Reports

By Neil Mansilla on .

Tests and monitors are useful for providing critical information that services are healthy and running as expected, particularly when notifications fire off when services are down. However, by the time the notification is received, we are immediately thrown into rescue mode. What if we could have avoided the crash altogether by simply analyzing environmental data, spotting the early indicators and making informed decisions that lead us away from the accident?

In the automobile industry, crash avoidance technologies monitor vehicle environmental and driver input data that suggest the potential for a collision. For example, if you’re veering into a lane without your turn signal, or you’re about to change lanes and another vehicle is in your blind spot, the crash avoidance system will deliver a series of audible and visual warnings to catch your attention, helping you to avoid a crash.

For APIs, Runscope provides several reports and testing features with Runscope Metrics, geared to help you detect issues that may be leading indicators to larger problems. Below we explore how to measure latency, the time that it takes for an API to respond to a request, and how Runscope can help you stay out in front of API performance.

Establish a Response Time Baseline 

The first step is to establish a baseline of latency metrics. The Runscope Radar Overview Report generates a comparison of any given result to these base metrics to give an indication of underlying problems. The request performance chart provides response times for different percentiles.

In the graph above, for the past 30 days, the mean response time is 505ms (50th percentile). The 95th percentile is 1149ms, meaning that 95% of the time, the response time is below 1149ms. Use these response times to establish a threshold of maximum response time on a test assertion—meaning that if a response takes longer than X milliseconds, Runscope will send a notification. In this case, we set an assertion stating that the request must take less than 1400ms to respond.

Above, we added a response time assertion on this test request. If the assertion fails, so will the test, and a notification will be sent. 

Keep Regular Tabs on Your API

As much as we can encourage you to check the overview page and performance metrics reports on Runscope, that practice doesn't always fit into a daily schedule. So instead, we created the Daily API Performance Report that's sent straight to your inbox.

The daily email report shown above provides average response times for the day along with a comparison to the previous day’s numbers. If you notice performance anomalies, digging in is just one click away. Clicking on the test name will bring you directly to that test’s Radar Overview Report.

Put Requests Under the Microscope

When you discover a critical error or suspect a performance hotspot, a useful tool for digging in is Runscope Traffic Inspector. Radar test results are stored in the Traffic Inspector log, with complete request and response details.

Above, we can filter down to the hostname and method (path), as well choose specific start and end times for the report, which helps to zoom in and potentially identify problem patterns indicated by escalating latency.

API Crash Avoidance in Practice

We can all agree that it’s better to find and fix small problems early before they grow into catastrophic failures. Establishing a baseline for response latency and setting up an assertion with a response time threshold is a useful first step. Once you've gotten into this practice, a useful next step is to regularly review reports to search for response times creeping up toward that threshold. With Runscope tools and reporting, you can stay ahead of the curve, building better software—not just fixing crashed services.

If you haven't already, sign up for Runscope for free to test out these metrics tools yourself.

Categories: howto, product, debugging

The Next Level in Collaboration: Share API Test Results

By Darrel Miller on .

We’ve talked before about the ability to share HTTP requests with team members and other people outside of your organization. This feature makes communicating about HTTP requests much easier than sending screenshots in emails or trying to describe HTTP header values over the phone. However, sometimes a single request doesn’t tell the whole story. Runscope is built to make collaboration a breeze, and now you can share entire Runscope test results with anyone with our new feature, shareable API test results.

A Link To The Big Picture

Runscope allows you to create a set of HTTP requests that exercise a particular API use case and assert that everything is working as expected. When a test fails, there is a problem to be solved that may require the input of several people. While developers on your team with a Runscope account can already see your tests and results, there may be developers, QA engineers or partners who need to be involved but do not have access to your Runscope dashboard. Being able to share test results containing details of each request and response by simply grabbing a single URL  saves valuable time when trying to communicate about and solve the problem.  

Developers on your team with a Runscope account can already see your tests and results, but what if you need to show the test to developers or QA people on other teams or even in another company? Creating a shareable test result is as easy as toggling the shareable flag at the upper right. By making a test result shareable, you are giving people a read-only view of your test results. This flag can be turned off at any time.

Sharing The Love

Chances are, if you are reading our blog, you’re already a Runscope user and you may have already seen this feature on the dashboard or seen the Changelog email announcing it. What you may not realize is there is another sneaky way you can use this feature to help improve your business.  

We regularly hear from customers who understand the value of using Runscope to test APIs and wish that other teams in their company were doing the same. By sharing test result URLs with other employees in your company, it may be just the thing you need to demonstrate the value of API monitoring. So why not go ahead and share with a coworker who you think could benefit from testing their APIs. 

Categories: howto, product, debugging

Everything is going to be 200 OK®