What's here
Once your API program is up and running you'll periodically encounter issues. When issues occur you can use Apigee's built in analytics to pinpoint issues and decide on a course of action. Here are some solutions to common problems you may encounter as you create and manage your API program. If you don't find your problem listed here, feel free to post your question on our forums
Possible causes
- There is a change in the number of users (fewer users = lower traffic)
- There is a change in the number of apps calling an API (fewer call s= lower traffic)
- There is a change in the ability of the API to handle traffic. The network may be down, or the API has a new Quota policy that is restricting traffic
- There is a change in the amount of legitimate traffic (i.e. real user calls vs. attacks). Attacks could be taking up your bandwidth
Try this
- Use contextual analytics to look for traffic spikes or drops
- Generate a traffic report to see which App have a change in the amount of traffic they are sending to an API
- Look at traffic for specific resources a period of time to see if individual resources are experiencing drops/spikes
Use contextual analytics
-
Go to main dashboard page (click the apigee logo).
-
Look for large changes in traffic in the All API traffic chart. This will give you sense of when the change occurred. Here you can see a spike occurred on in mid August. When investigate further you'll want to look at this time period in particular.
-
Also check the Top API movers chart. You can see that which APIs had the highest drop or increase in traffic.
Generate a custom traffic report
A custom traffic report will let you examine specific apps and URIs to see exactly where the problem is occurring. The report will tell which apps have had a change in traffic. For each app you can see the traffic trend for all the APIs the app calls. You create an App traffic report by using apps the main measure with drill down on the requested URI by app.
Set up the primary measure
- On the Analytics tab, click the + Custom Report button.
- Enter App Traffic Report as the Report Name.
- Enter a brief description of the report in the Report Description field.
- Select prod from the Environment menu.
- Select message_count as the Primary Measure. This will let you see traffic data.
Set up data display
- Select Count as the Function.
- Select Column as the Chart type.
- Select Hourly as the Chart Refresh Interval.
Set up chart drill down
These selection will determine how you can refine the view of your content.
- Choose developer_app as Drilldown 1. Use this measure to see all the apps in your org. This lets you see the traffic by app.
- Choose request_uri as Drilldown 2. This dimension will break up the traffic by API.
- Click Save to generate the report.
Analyze the report
- Look for an App that's showing a large change in traffic. You can change the time period to see traffic trends over time.
- Click on the app you want review to drill down into more details. Again, using the time period menu, can view requests made by the App over various time periods to understand the nature of the traffic spike or drop. Look to see if individual resources are seeing a drop in the traffic or if it's the whole API. If only one resource is seeing a drop, it points to a possible network issue or reduced usage of a specific resource.
Decide on an action
If you're see a drop in an individual resource you may want to investigate your network infrastructure. If you're seeing unusual traffic patterns to your apps you may be under an attack that is eating up your bandwidth. If you're seeing a traffic increase to the whole API you may want to examine how the API is configured. You may have a policy that is limiting your traffic. In this case you can use Trace to inspect the message flow of your API.
Possible causes:
- If the slowness being seen by just one app or is it from multiple apps? If one app, then it might be a problem with the app.
- If it being seen by multiple users across multiple apps and users seem to be in the same geo location, then it could be a network issue
- If you're not seeing either of these issue, it could be an issue on the gateway. If you recently added or updated a policy. It could be configured incorrectly.
- If the total response time is being reported as high, but the average endpoint response time has not changed then it might be an Apigee issue. If the average endpoint response time is also high then it could be an issue in the network between Apigee and the target server, or an internal application server
Try this:
- Use contextual analytics to identify which API is showing an increased response time
- Use Trace to figure out if the increased response time is happening in your live traffic
- Generate a latency report to figure out exactly which API and resource is causing the issue
Use contextual analytics to identify the issue
- Click API in the main menu.
- On the Performance section, click the Metrics menu and choose Average Response Time.

The chart will show you the response time for all your APIs. Look for spikes or gradual increases in response time. You should be able to quickly see which API is having an issue.
Run a trace to identify the bottleneck
Trace tells you if the problem that's being reported is happening right now. It lets you identify where exactly the slow API is occurring in your live traffic
- Click on the API that seems slower than usual (in this example we used StickerAPI). The API's details page will appear
- Click the Trace button to set up a trace session for the API. This will help you better understand where the bottleneck is occurring.
For example in this trace session you might see that a POST call is taking much longer than GET calls.
Create a custom report
Create a new report to measure max latency by app and resource. This report lets you figure out if there is a pattern of service issues. You can use this as yet another data point to identify the issue.
Set up the basics and data display
- On the Analytics tab, click the + Custom Report button.
- Enter Latency Report as the Report Name.
- Enter a brief description of the report in the Report Description field.
- Select Column as the Chart type.
- Select prod from the Environment menu.
- Select Hourly as the Data Aggregation Interval.
- Select total_response_time as the Primary Measure.

Set up aggregation an Y-axis measures
- Select Max as the Aggregation Function.
- Select Total Response Time as Measure 1. This will be the primary measure for the report.

Set up chart drill down
These selection will determine how you can refine the view of your content.
- Choose API Proxy as Drilldown 1. This measure lets you see the response time of all the APIs in your org.
- Choose Request Path as Drilldown 2. This dimension will break up the responses by the actual resources in an API. So using this drilldown you can see the response time by resource.

Analyze the report
The new latency report will show you the response times by API and then by each resource within an API. By combining this information with what you know about your network architecture, you can quickly find issues that may be related to your infrastructure.
- Locate the worst performing API (that is, the one with the highest latency).

- Drill down by selecting the API and view the worst performing resource.

Decide on an action
Now that you know which resource is performing badly, you can examine your network to see if there's a service issue, or you can add a 3rd dimension like developer_app to see which Apps are impacted by this slow resources, or developer to figure out which developers that are impacted by the slow resource.