Cloud Interconnects Traffic report

The Cloud Interconnects report allows you to estimate how much of your cloud origin egress traffic is successfully sent through Private Network Interconnects (PNIs).

The Cloud Interconnects behavior maximizes traffic flow through PNIs provided by some cloud hosting providers.

The KPI sections show estimated Total Traffic, Traffic over PNIs, and percentage of Traffic using PNIs. The report presents bytes only.

📘

The report dates are in GMT. Your cloud service usage report may show dates in local time, so take this into account if comparing ​Akamai​ reported origin traffic against your cloud provider’s reporting.

Filters
Select at least one required filter in every report. For optional filters, making no selection returns all associated data for that filter.

• CP code (required). Content provider (CP) codes let you segment your delivered content for tracking and reporting purposes. All CP codes have ties to one or more services, which are tracked and reported under that CP code.

• Groups (optional). Groups let you narrow down your content to groups of CP codes.

Metrics

KPI metrics

• Origin. Estimated bytes served from cloud origins for time period.

• Interconnects. Estimated cloud origin bytes served through PNIs for time period.

• Interconnects vs. Origin. Estimated PNI egress traffic as opposed to cloud origin egress traffic.

Interconnect usage (chart) metrics

• Origin traffic. Estimated bytes of traffic from cloud origins for date range.

• PNI traffic. Estimated bytes of traffic egressing through PNIs for date range.

Interconnect traffic by CP code (table) metrics

• CP code. Content provider code.

• Origin bytes. Estimated bytes of traffic from cloud origin for this CP code over this time frame.

• PNI bytes. Estimated bytes of traffic egressing through PNIs for this CP code over this time frame.

• PNI bytes %. Estimated PNI bytes / cloud origin bytes for this CP code and time frame.

📘

Traffic in portions of Southeast Asia may not accurately reflect PNI usage, even though those connections are utilized.

Traffic report

The Traffic report provides hits, volume, bandwidth, and offload data over time for your web delivery products.

This means edge traffic (traffic from the edge servers to end users), midgress traffic (traffic between the servers), and origin traffic (traffic from your origin). You can choose to show the base metrics for the page in hits or bytes. Some filters and metrics depend on your selection.

Depending on whether the cacheability filter is enabled or not, the offload graph is yellow (for cacheable) or purple (for non cacheable) data. There is no offload for non cacheable content.

📘

The metrics show average traffic data (not peak).

Filters
Select at least one required filter in every report. For optional filters, making no selection returns all associated data for that filter.

• CP code (required). Content provider (CP) codes let you segment your delivered content for tracking and reporting purposes. All CP codes have ties to one or more services, which are tracked and reported under that CP code.

• Groups (optional). Groups let you narrow down your content to groups of CP codes.

• Cacheability. Distinguishes cacheable content from non cacheable content. Selecting a non-cacheable filter lets you see non-cacheable traffic even if offload is zero, offload for content that is redirected responses served from the edge, and offload for content generated at the edge.

• Delivery type (optional). Distinguishes secure traffic from non-secure traffic.

• IP (optional). Supported array values are IPv4 and IPv6. If no IP version is selected, the report shows data for both IPv4 and IPv6.

• Response status (optional). An indicator showing success or failed HTTP response.

• Response class (optional). A class of HTTP response status codes, from 0XX through 6XX.

• Response code (optional). An HTTP response status code, for example, 404.

• Traffic (optional). HTTP traffic to be included in the report data.

  • All Responses - Includes all response traffic.
  • PUT/POST Responses - Response traffic from PUT and POST operations.
  • GET/HEAD Responses - Response header traffic from GET operations.
  • PUT/POST Requests - Request traffic from PUT and POST operations.

• HTTP Method. A request method indicating the action performed on a resource.

Metrics

• Bytes offload. The volume of traffic served by ​Akamai​ that did not require hits on your origin.

• Average bytes offload. The average volume that was served from cache as a percentage of total volume served.

• Maximum bytes offload. The peak volume that was served from cache as a percentage of total volume served.

• Minimum bytes offload. The lowest volume that was served from cache as a percentage of total volume served.

• Edge bits per second. The edge bandwidth for given objects and filters.

• Maximum edge bits per second. The peak edge bandwidth for given objects and filters.

• Minimum edge bits per second. The lowest edge bandwidth for given objects and filters.

• Total edge bytes. The total volume of edge traffic for given objects and filters.

• Edge hits per second. The number of edge requests per second for given objects and filters.

• Maximum edge hits per second. The peak number of edge requests per second for given objects and filters.

• Minimum edge hits per second. The lowest number of edge requests per second for given objects and filters.

• Total edge hits. The total number of edge requests for given objects and filters.

• Hits offload. The number of hits that served as a percentage of total hits for given objects and filters.

• Average hits offload. The average number of hits that served as a percentage of total hits served for given objects and filters.

• Maximum hits offload. The peak number of hits that served as a percentage of total hits served for given objects and filters.

• Minimum hits offload. The lowest number of hits that served as a percentage of total hits served for given objects and filters.

• Midgress bits per second. The bandwidth between servers for given objects and filters.

• Maximum midgress bits per second. The peak bandwidth measurement between servers for given objects and filters.

• Minimum midgress bits per second. The lowest bandwidth measurement between servers for given objects and filters.

• Maximum origin bits per second. The peak origin bandwidth for given objects and filters.

• Total midgress bytes. Volume delivered between servers for given objects and filters.

• Midgress hits per second. The number of requests between servers per second for given objects and filters.

• Maximum midgress hits per second. The peak number of requests between servers per second for given objects and filters.

• Minimum midgress hits per second. The lowest number of requests between servers per second.

• Total midgress hits. All hits with all response codes delivered between servers.

• Origin bits per second. The origin bandwidth for given objects and filters.

• Minimum origin bits per second. The lowest origin bandwidth.

• Total origin bytes. The total volume of origin traffic for given objects and filters.

• Origin hits per second. The number of origin requests per second for given objects and filters.

• Maximum origin hits per second. The peak number of origin requests per second for given objects and filters.

• Minimum origin hits per second. The lowest number of origin requests per second for given objects and filters.

• Total origin hits. The total number of origin requests for given objects and filters.

• Edge hits per second by response class. The rate of edge requests per second by HTTP response class for given objects and filters, for example, 2xx.

• Origin hits per second by response class. The rate of origin requests per second by HTTP response class for given objects and filters, for example, 2xx.

• Edge hits by response class. The number of edge requests by HTTP response class for given objects and filters, for example, 2xx.

• Edge hits percent by response class. The number of edge requests per second by HTTP response class, for example, 2xx, as a percent of all edge hits.

• Origin hits by response class. The number of origin requests per second by HTTP response class for given objects and filters, for example, 2xx.

• Origin hits percent by response class. The number of origin requests per second by HTTP response class for given objects and filters, for example, 2xx, as a percent of all edge hits.

• Edge hits by response. Edge hits by response.

• Edge hits percent by response. Edge hits percent by response.

• Origin hits by response. Origin hits by response.

• Origin hits percent by response. The number of origin requests per second by HTTP response for given objects and filters, such as 201, as a percent of all edge hits.

• Maximum midgress hits. The peak number of requests between servers out of 5 minute data chunks for the given objects and filters.

• Maximum origin hits. The peak number of origin requests out of 5 minute data chunks.

• Maximum edge hits. The peak number of edge requests out of 5 minute data chunks.

• Maximum midgress bytes. The maximum volume delivered between servers out of 5 minute data chunks.

• Maximum edge bytes. The maximum volume of edge traffic out of 5 minute data chunks.

• Maximum origin bytes. The maximum volume of origin traffic out of 5 minute data chunks.

• Edge hits by HTTP version. The request count delivered from ​Akamai​ edge servers to the end user by request method.

• Edge hits percentage by HTTP version. The portion of all requests delivered from ​Akamai​ edge services to the end user by request method.

• Edge bytes by HTTP version. The volume for the traffic delivered from ​Akamai​ to the end user by request method.

• Edge bytes percentage by HTTP version. Edge bytes percent by request method

📘

Be aware that changes to your Property configuration, such as cache settings may in turn change the shape of data subsequently reported.

Today's Traffic report

Today's Traffic Report provides hits, volume, bandwidth, and offload data for the most recent 48 hours for your Web delivery products.

Edge traffic (traffic from the edge servers to end users), midgress traffic (traffic between the servers), and origin traffic (traffic from your origin) are called out. You can choose whether you want the base metric for the page to be hits or bytes.

📘

The metrics show average traffic data (not peak).

Data granularity
The default granularity for this report, which shows data for the last 48 hours, in five-minute intervals.

Filters
Select at least one required filter in every report. For optional filters, making no selection returns all associated data for that filter.

• CP code (required). Content provider (CP) codes let you segment your delivered content for tracking and reporting purposes. All CP codes have ties to one or more services, which are tracked and reported under that CP code.

• Groups (optional). Groups let you narrow down your content to groups of CP codes.

• Response class (optional). A class of HTTP response status codes (0XX, 1XX, 2XX, 3XX, 4XX, 5XX, 6XX ).

• Response status (optional). An indicator of whether the HTTP response was successful or failed.

Metrics

• Bytes offload. The volume of traffic served by ​Akamai​ that did not require hits on your origin.

• Average bytes offload. The average volume that was served from cache as a percentage of total volume served.

• Maximum bytes offload. The peak volume that was served from cache as a percentage of total volume served.

• Minimum bytes offload. The lowest volume that was served from cache as a percentage of total volume served.

• Edge bits per second. The edge bandwidth for given objects and filters.

• Maximum edge bits per second. The peak edge bandwidth for given objects and filters.

• Minimum edge bits per second. The lowest edge bandwidth for given objects and filters.

• Total edge bytes. The total volume of edge traffic for given objects and filters.

• Edge hits per second. The number of edge requests per second for given objects and filters.

• Maximum edge hits per second. The peak number of edge requests per second for given objects and filters.

• Minimum edge hits per second. The lowest number of edge requests per second for given objects and filters.

• Total edge hits. The total number of edge requests for given objects and filters.

• Hits offload. The number of hits that served as a percentage of total hits.

• Average hits offload. The average number of hits that served as a percentage of total hits served for the given objects and filters.

• Maximum hits offload. The peak number of hits that served as a percentage of total hits served for the given objects and filters.

• Minimum hits offload. The lowest number of hits that served as a percentage of total hits served for the given objects and filters.

• Midgress bits per second. The bandwidth between servers for given objects and filters.

• Maximum midgress bits per second. The peak bandwidth measurement between servers for given objects and filters.

• Minimum midgress bits per second. The lowest bandwidth measurement between servers for given objects and filters.

• Maximum origin bits per second. The peak origin bandwidth for given objects and filters.

• Total midgress bytes. Volume delivered between servers for the given objects and filters.

• Midgress hits per second. The number of requests between servers per second for the given objects and filters.

• Maximum midgress hits per second. The peak number of requests between servers per second for the given objects and filters.

• Minimum midgress hits per second:. The lowest number of requests between servers per second for the given objects and filters.

• Total midgress hits. All hits with all response codes delivered between servers.

• Origin bits per second. The origin bandwidth for given objects and filters.

• Minimum origin bits per second. The lowest origin bandwidth for given objects and filters.

• Total origin bytes. The total volume of origin traffic for given objects and filters.

• Origin hits per second. The number of origin requests per second for given objects and filters.

• Maximum origin hits per second. The peak number of origin requests per second for given objects and filters.

• Minimum origin hits per second. The lowest number of origin requests per second for given objects and filters.

• Total origin hits. The total number of origin requests for given objects and filters.

📘

Be aware that you affect report data by configuring details such as cache settings, or by making changes to a configuration within the time period of the report you're viewing.

Traffic by Geography report

The Traffic by Geography report returns traffic data by country or area. This report shows only 200 OK hits.

Filters
Select at least one required filter in every report. For optional filters, making no selection returns all associated data for that filter.

• CP code (required). Content provider (CP) codes let you segment your delivered content for tracking and reporting purposes. All CP codes have ties to one or more services, which are tracked and reported under that CP code.

• Groups (optional). Groups let you narrow down your content to groups of CP codes.

• Delivery type (optional). Distinguishes secure from non-secure traffic.

• Country/area (optional). The country or area generating traffic.

• HTTP Method. A request method indicating the action performed on a resource.

Metrics

• Edge hits. The number of edge requests for given objects and filters.

-Edge bytes. The number of edge bytes for given objects and filters.

• Country/area. The country or area generating traffic.

📘

Be aware that changes to your Property configuration, such as cache settings may in turn change the shape of data subsequently reported.

Traffic by Server Country report

The Traffic by Server Country report returns daily traffic data by server country or region.

API Acceleration traffic is identified by Small Payload Size (less than 5kB), single transactions and low cacheability. Any traffic that is served as a response for the API requests generated by the clients constitutes for this traffic.

This report gives you the Usage Traffic by Hits and Bytes for all API acceleration traffic from a designated Server Country (served from). The data you get is very close to billing metrics you can see in your invoice.

Filters
Select at least one required filter in every report. For optional filters, making no selection returns all associated data for that filter.

• CP code (required). Content provider (CP) codes let you segment your delivered content for tracking and reporting purposes. All CP codes have ties to one or more services, which are tracked and reported under that CP code.

• Groups (optional). Groups let you narrow down your content to groups of CP codes.

• Delivery type (optional). Distinguishes secure from non-secure traffic.

• Country/area (optional) . The country or area generating traffic.

Metrics

• Total hits. The number of edge requests for given objects and filters.

• Total bytes. The total number of bytes being served from the country or region.

Traffic by Browser and OS report

The Traffic by Browser and OS report provides information about what browser types and operating systems are generating traffic.

Filters
Select at least one required filter in every report. For optional filters, making no selection returns all associated data for that filter.

• CP code (required). Content provider (CP) codes let you segment your delivered content for tracking and reporting purposes. All CP codes have ties to one or more services, which are tracked and reported under that CP code.

• Groups (optional). Groups let you narrow down your content to groups of CP codes.

Metrics

• Hits by browser. The number of edge requests by browser type.

• Percent hits by browser. The percent of all edge requests for the identified browser.

• Hits by OS. The number of edge requests by operating system.

• Percent hits by OS. The percent of all edge requests for the given operating system.

📘

Be aware that changes to your Property configuration, such as cache settings may in turn change the shape of data subsequently reported.

Top Visitors report

📘

This report will be affected by the Delivery Reports Consolidation initiative. Learn more in the Delivery Reports Consolidation guide.

For the top unique IP/user agent combinations, the following information is provided.

• Domain/IP. The domain, if known, and the IP address from which the visitor is requesting your content.

• Hits. The number of OK or successful hits on your content this visitor is producing. This number includes hits on the edge server from the end user with successful response codes only (such as 2xx, 3xx, 0xx).

• Volume. The amount of bandwidth this visitor is using to request your content. This number includes hits on the edge server from the end user with successful response codes only (such as 2xx, 3xx, 0xx).

Page Views report

The Page Views report returns page view (text/HTML) file data over time. The page views count doesn't include pages with response codes 301, 302, and 404. It does include pages with 403 and 400 response codes.

Filters
Select at least one required filter in every report. For optional filters, making no selection returns all associated data for that filter.

• CP code (required). Content provider (CP) codes let you segment your delivered content for tracking and reporting purposes. All CP codes have ties to one or more services, which are tracked and reported under that CP code.

• Groups (optional). Groups let you narrow down your content to groups of CP codes.

Metrics

• Page views. The total number of page views.

• Minimum page views per second. The lowest rate of page file delivery per second.

• Maximum page views per second. The highest rate of page file delivery per second.

📘

Be aware that changes to your Property configuration, such as cache settings may in turn change the shape of data subsequently reported.

Unique Visitors report

📘

This report will be affected by the Delivery Reports Consolidation initiative. Learn more in the Delivery Reports Consolidation guide.

The Unique Visitors report returns unique visitor data over time. Unique visitors are determined by unique combinations of end user IP addresses plus user agent.

Filters
Select at least one required filter in every report. For optional filters, making no selection returns all associated data for that filter.

• CP code (required). Content provider (CP) codes let you segment your delivered content for tracking and reporting purposes. All CP codes have ties to one or more services, which are tracked and reported under that CP code.

• IP (optional). Supported array values are IPv4 and IPv6. If no IP version is selected, the report shows data for both IPv4 and IPv6.

Metrics

• Unique visitors. The number of unique combinations of client IP addresses plus user agent.

• Average unique visitors. The average number of unique combinations of client IP addresses plus user agent for the selected date range.

📘

Be aware that changes to your Property configuration, such as cache settings may in turn change the shape of data subsequently reported.

Daily Unique Visitors report

📘

This report will be affected by the Delivery Reports Consolidation initiative. Learn more in the Delivery Reports Consolidation guide.

The Daily Unique Visitors report returns daily data for unique combinations of IP address and user agent. When querying multiple days worth of data, you receive the maximum (MAX) daily value across the entire date range for each of the dimensions.

Filters
Select at least one required filter in every report. For optional filters, making no selection returns all associated data for that filter.

• CP code (required). Content provider (CP) codes let you segment your delivered content for tracking and reporting purposes. All CP codes have ties to one or more services, which are tracked and reported under that CP code.

• Groups (optional). Groups let you narrow down your content to groups of CP codes.

Metrics

📘

When querying multiple days worth of data, you receive the maximum daily value across the entire date range.

• Average unique visitors. The average number of unique combinations of client IP addresses plus user agent for the selected date range.

• Minimum unique visitors. The lowest number of unique combinations of client IP addresses plus user agent for the selected date range.

• Maximum unique visitors. The highest number of unique combinations of client IP addresses plus user agent for the selected date range.

• Unique visitors by country/area. The number of unique combinations of client IP addresses plus user agent by country or area.

• Unique visitors by state. The number of unique combinations of client IP addresses plus user agent by U.S. state.

• Unique visitors by province. The number of unique combinations of client IP addresses plus user agent by Canadian province.

• Unique visitors by browser. The number of unique combinations of client IP addresses plus user agent by browser.

• Percent unique visitors by browser. The percent of all unique combinations of client IP addresses plus user agent for this browser.

• Unique visitors by OS. The number of unique combinations of client IP addresses plus user agent by operating system.

• Percent unique visitors by OS. The percent of all unique combinations of client IP addresses plus user agent for this operating system.

URL Traffic report

The URL Traffic report delivers traffic data by URL. You can choose to view this report by hits or bytes.

Key performance indicator (KPI) results are different for URL Traffic and Traffic report. The KPIs are based on all URL data.

HTTP URL data is stored only for URLs with at least 50 hits per day. This means that URLs with less than 50 hits per day are excluded from single day reports and reports that span multiple days will under-report the traffic for some URLs. The 50 hit requirement is in place to prevent customers with a large number of distinct URLs with few hits from overwhelming the reporting systems. This requirement has an impact on data returned by report. This explains why you may observe differences between URL responses and URL traffic reports.

Filters
Select at least one required filter in every report. For optional filters, making no selection returns all associated data for that filter.

• CP code (required). Content provider (CP) codes let you segment your delivered content for tracking and reporting purposes. All CP codes have ties to one or more services, which are tracked and reported under that CP code.

• Groups (optional). Groups let you narrow down your content to groups of CP codes.

• Responses. You can select Error or Success.

• Delivery type (optional). Distinguishes secure from non-secure traffic.

• URL string. The portion of a URL with report data you want to see. You can put limits on the search with a custom string search (using the following match criteria: Contains, Starts with, Ends with, Does not contain, Does not start with, Does not end with, Match a regular expression, Does not match a regular expression, or Is an exact match ). You can also add a URL pattern to match, such as a file type extension or part of a directory name.

Metrics

• Average hits offload. The average number of hits that served from cache as a percentage of total hits served, for given objects and filters.

• Maximum hits offload. The peak number of hits that served from cache as a percentage of total hits, for given objects and filters.

• Minimum hits offload. The lowest number of hits that served from cache as a percentage of total hits, for given objects and filters.

• Total edge hits. The total number of edge requests, for given objects and filters.

• Maximum edge hits per second. The peak number of edge requests per second, for given objects and filters.

• Minimum edge hits per second. The lowest number of edge requests per second, for given objects and filters.

• Total origin hits. The total number of origin requests, for given objects and filters.

• Maximum origin hits per second. The peak number of origin requests per second, for given objects and filters.

• Minimum origin hits per second. The lowest number of origin requests per second, for given objects and filters.

• Edge hits. The number of requests delivered by ​Akamai​ for the associated URL.

• Origin hits. The number of requests delivered by the origin for the associated URL.

• Offload. The average number of hits delivered by ​Akamai​ for this URL as a percentage of total hits, for given objects and filters.

• Average bytes offload. The average volume that was served as a percentage of total volume served.

• Maximum bytes offload. The peak volume that was served as a percentage of total volume served.

• Minimum bytes offload. The lowest volume that was served as a percentage of total volume served.

• Total edge bytes. The total volume of edge traffic, for given objects and filters.

• Maximum edge bits per second. The highest rate of edge requests per second, for given objects and filters.

• Minimum edge bits per second. The lowest rate of edge requests per second, for given objects and filters.

• Total origin bytes. The total volume of origin traffic, for given objects and filters.

• Maximum origin bits per second. The highest rate of origin requests per second, for given objects and filters.

• Minimum origin bits per second. The lowest rate of origin requests per second, for given objects and filters.

Top URLs edge hits / top URLs edge bytes
Provides traffic data for the top 5000 URLs with the highest number of edge hits or edge bytes associated with given objects and filters.

• Edge. The total volume of edge traffic for this URL.

• Origin. The total volume of origin traffic for this URL.

• Offload. The total volume of traffic delivered by ​Akamai​ as a percentage of total volume served. For a specific URL.

• URL. The URL of the specific content.

URL Responses report

The URL Responses report delivers HTTP response data by URL.

HTTP URL data is stored only for URLs with at least 50 hits per day. This means that URLs with less than 50 hits per day are excluded from single day reports and reports that span multiple days will under-report the traffic for some URLs. The 50 hit requirement is in place to prevent customers with a large number of distinct URLs with few hits from overwhelming the reporting systems. This requirement has an impact on data returned by report. This explains why you may observe differences between URL responses and URL traffic reports.

Filters
Select at least one required filter in every report. For optional filters, making no selection returns all associated data for that filter.

• CP code (required). Content provider (CP) codes let you segment your delivered content for tracking and reporting purposes. All CP codes have ties to one or more services, which are tracked and reported under that CP code.

• Groups (optional). Groups let you narrow down your content to groups of CP codes.

• Responses. You can select Error or Success.

• Delivery type (optional). Distinguishes secure from non-secure traffic.

• URL string. The portion of a URL with report data you want to see. You can put limits on the search with a custom string search (using the following match criteria: Contains, Starts with, Ends with, Does not contain, Does not start with, Does not end with, Match a regular expression, Does not match a regular expression, or Is an exact match ). You can also add a URL pattern to match, such as a file type extension or part of a directory name.

Metrics (for given objects and filters)

• Total edge hits. The total number of edge requests.

• Maximum edge hits per second. The peak number of edge requests per second.

• Minimum edge hits per second. The lowest number of edge requests per second.

Top URLs edge hits by responses
Provides traffic data for the top 5000 URLs with the highest number of responses associated with given objects and filters.

• 0XX. The number of HTTP responses in the 0XX range for this URL.

• 2XX. The number of HTTP responses in the 2XX range for this URL.

• 3XX. The number of HTTP responses in the 3XX range for this URL.

• 4XX. The number of HTTP responses in the 4XX range for this URL.

Origin Performance report

The Origin Performance report shows performance characteristics observed by ​Akamai​ edge servers when making requests to your origin servers. Metrics are collected as a request travels from the edge servers to your origin, and the associated response travels from your origin to the edge servers. The request/response represents an exchange between the edge servers and your origin.

Filters
Select at least one required filter in every report. For optional filters, making no selection returns all associated data for that filter.

• CP code (required). Content provider (CP) codes let you segment your delivered content for tracking and reporting purposes. All CP codes have ties to one or more services, which are tracked and reported under that CP code.

• Cacheability.
  Cacheable. Can be stored after an initial request for faster future delivery.
  Non-cacheable. Can't be stored (identified as "no-store" or have a 0 TTL) and always trigger an origin request.

• Response Codes. HTTP response codes from your origin to edge servers.

Metrics

• Origin response. The number of responses from your origin to edge servers.

• Maximum origin responses. The highest number of responses from your origin to edge servers for the selected date range.

• Origin response times. The elapsed time in milliseconds for request/response exchanges from ​Akamai​ edge servers to your origin.

• Maximum origin response times. The highest elapsed time in milliseconds for request/response exchanges from ​Akamai​ edge servers to your origin.

• Average origin response times. The average elapsed time in milliseconds for request/response exchanges from ​Akamai​ edge servers to your origin for the selected date range.

📘

Important factors that contribute to exchange time include geography between edge servers and origin, network conditions, and performance of your origin. Also, be aware of your caching settings.

SureRoute Performance report

📘

This report will be affected by the Delivery Reports Consolidation initiative. Learn more in the Delivery Reports Consolidation guide.

SureRoute tests multiple routes between the edge server and the origin. These tests identify an optimal path for performance and establish alternative routes in cases of potential request failures.

The identified optimal path is used to improve performance with non-cacheable content. When SureRoute is enabled, edge servers request the same test object from the origin via three different routes, using the results of these occasional "races" to determine an optimal route to the origin.

The SureRoute Performance report shows the percentage of traffic traveling SureRoute's faster route. This report is based on the logs retrieved from the ​Akamai​ edge servers.

Route optimization data requires having a SureRoute test object available on your origin. If your report is not showing any data, make sure you've completed this configuration step.
If your SureRoute configuration uses custom maps, some origin hostnames may not show. In this case contact your representative to check that all origin hostnames are on your custom SureRoute map.

Keep in mind that the races to fetch the test object result in a small increase in origin traffic.

📘

SureRoute is automatically turned off for cacheable content. For the best performance you should serve it from an edge server cache and not over an origin route.

Data retention and granularity
The SureRoute Performance report is a real-time report that shows data for up to the last 10 days.

Filters
Select at least one required filter in every report. For optional filters, making no selection returns all associated data for that filter.

• CP code (required). Content provider (CP) codes let you segment your delivered content for tracking and reporting purposes. All CP codes have ties to one or more services, which are tracked and reported under that CP code.

Metrics (for the selected date range)

• Route optimization, in percentage of optimized requests. The bandwidth reduction for your origin, expressed as the percentage of optimized requests or the percentage of requests where SureRoute provided a faster route. This is an aggregate view of traffic from the edge compared to traffic going to your origin.

• Average route optimization. The average percentage of requests where SureRoute provided a faster route.

• Minimum route optimization. The lowest percentage of requests where SureRoute provided a faster route.

• Maximum route optimization. The highest percentage of requests where SureRoute provided a faster route.

Prefetching report

📘

This report will be affected by the Delivery Reports Consolidation initiative. Learn more in the Delivery Reports Consolidation guide.

Prefetching instructs the ​Akamai​ edge server to retrieve embedded HTML content (objects), such as images and scripts, from the origin before the browser requests these objects. This can significantly decrease the load time and the display time of embedded objects.

The Prefetching report provides insight into the volume of responses served by the edge and your origin server when you are using the ​Akamai​ Instant (Page Prefetching) behavior in your ​Akamai​ configuration. Responses are based on time frame, traffic segments, and traffic type.

How you choose to set up ​Akamai​ Instant and other caching rules can affect the data in this report. Cacheability attributes of objects, in particular, have specific requirements for configuration.

Data granularity and retention
The Prefetching report shows data for the last 10 days. Date ranges up to two days show five-minute data, and ranges more than two days to 14 days show hourly data.

Filters
Select at least one required filter in every report. For optional filters, making no selection returns all associated data for that filter.

• CP code (required). Content provider (CP) codes let you segment your delivered content for tracking and reporting purposes. All CP codes have ties to one or more services, which are tracked and reported under that CP code.

• Cacheability.
  Cacheable. Can be stored after an initial request for faster future delivery.

  • Must have Tiered Distribution enabled.
  • Must have a defined caching rule based on either filenames or URL extensions.
  • Must appear in the HTML tags: base, img, script, input, link, table, td, or th. Prefetching of cacheable content requires that you enable Tiered Distribution for that content.
    Non-cacheable. Can't be stored (identified as "no-store", or has a 0 TTL) and always triggers an origin request.
  • Must have SureRoute enabled.
  • The URL must end in either one of the following extensions.
  • The URL must be a request for a default file in a directory, as specified by ending in a "/". For example, "http://www.example.com/product/".
  • The URL appear in one of the following HTML tags: base, img, script, input, link, table, td, or th.

Metrics

• Edge responses. The total number of all responses from the edge server to the end user.

• Origin responses. The total number of all responses served from the origin.

• Edge prefetch responses. The total number of edge cache hits for request messages correlated to no-store or low TTL objects. This value can be zero when it is related to no-store content.

• Origin prefetch responses. The total number of responses served from the origin for prefetch requests, which includes embedded objects and ​Akamai​ Instant requests for prefetched pages.

• Edge responses (per second). The rate of all responses from the edge server to the end user, in responses per second.

• Maximum edge responses (per second). The highest rate of all responses from the edge server to the end user, in responses per second, for the selected date range.

• Latest edge responses (per second). The most recent measurement of the rate of all responses from the edge server to the end user, in responses per second, for the selected date range.

• Origin responses (per second). The rate of all responses served from the origin.

• Maximum origin responses (per second). The highest rate of all responses served from the origin, for the selected date range.

• Latest origin responses (per second). The most recent measurement of the rate of all responses served from the origin, for the selected date range.

• Origin prefetch responses (per second). The rate of responses served from the origin for prefetch requests, which includes embedded objects and ​Akamai​ Instant requests for prefetched pages, for the selected date range.

• Maximum origin prefetch responses (per second). The highest rate of responses served from the origin for prefetch requests, which includes embedded objects and ​Akamai​ Instant requests for prefetched pages, for the selected date range.

• Latest origin prefetch responses (per second). The most recent measurement of the rate of responses served from the origin for prefetch requests, which includes embedded objects and ​Akamai​ Instant requests for prefetched pages, for the selected date range.

• Edge prefetch responses (per second). The rate of edge cache hits for request messages correlated to no-store or low TTL objects. This value can be zero when it is related to no-store content.

• Maximum edge prefetch responses (per second). The highest rate of edge cache hits for request messages correlated to no-store or low TTL objects for the selected date range. Note that this value can be zero when it is related to no-store content.

• Latest edge prefetch responses (per second). The most recent measurement of the rate of edge cache hits for request messages correlated to no-store or low TTL objects for the selected date range. This value can be zero when it is related to no-store content.

Proxy Protection report

📘

This report will be affected by the Delivery Reports Consolidation initiative. Learn more in the Delivery Reports Consolidation guide.

This report shows how ​​Akamai​​'s Enhanced Proxy Detection (EPD) service applies proxy detection and location spoofing protection when delivering your content.
EPD uses services provided by our data provider, GeoComply to identify requests for your content that have been redirected from an unwanted source through proxy. You can then allow, deny, or redirect these requests.

Fixed categories of proxy detection

​​Akamai​​ leverages GeoComply's GeoGuard product for proxy detection. GeoGuard offers multiple categories to identify various types of unwanted proxy that may be used in a request. A list of these categories is kept on GeoComply's website.

When setting up EPD in your property configuration, you can select one of two Configuration Modes:

• Best Practices. This is the mode ​​Akamai​​ recommends. It automatically uses all of GeoGuard's primary ("must-have") categories and you set a single action to apply for all of them — "Set it, and forget it."
• Advanced. This lets you pick and choose from the "must-have" and "optional" categories and you can customize individual actions for each.

Remember how you've set your Configuration Mode when reviewing report data here. It impacts how data is revealed—whether it is, or isn't displayed in some cases.

Use the Proxy Protection report

1. From the Reports menu or Reporting overview page, select the Proxy Protection report.
2. Select filters:
   1. Date range (required). Click the date picker icon to adjust the date and time.
   2. Groups and Properties. Narrow down your content to groups of CP codes.
   3. CP codes (required). Select CP codes.
   4. IP Version. Select the applicable IP version for traffic — IPV4 or IPV6.
   5. HTTP version. Select the applicable version, either HTTP, HTTPS/1.1, HTTP/2, or HTTP/3
3. Click Apply.
   The report loads with the following widgets:
   • KPI summary: Edge proxy hits (total), Applied matches (total), Actions taken (total).
   • Edge proxy hits, applied matches, and actions taken
   • Edge proxy hits, applied matches, and actions taken by CP code
   • Match category trend
   • Match category by CP code
   • Actions taken trend
   • Actions taken by CP code
     For descriptions, see Widgets table.
4. To see results for a higher number of hostnames, access the widget data through API calls:
   1. Click the API calls icon next to the widget.
   2. Copy the API call into your API tool and run.
      For general information on how the reporting API works, see Reporting API.

Filters
Select at least one required filter in every report. For optional filters, making no selection returns all associated data for that filter.

• CP code (required). Content provider (CP) codes let you segment your delivered content for tracking and reporting purposes. All CP codes have ties to one or more services, which are tracked and reported under that CP code.
• Groups and Properties (optional). Groups let you narrow down your content to groups of CP codes.
• Delivery type (optional). Distinguishes secure traffic from non-secure traffic.
• IP (optional). Supported array values are IPv4 and IPv6. If no IP version is selected, the report shows data for both IPv4 and IPv6.
• HTTP version (optional): Either HTTP, HTTPS/1.1, HTTP/2, or HTTP/3.

Widgets

Metrics

actionsTaken - Actions Taken
actionsTakenTotal - Total Actions Taken
akamaiOverride - Akamai Override Hits
akamaiOverrideTotal - Total Akamai Override
appliedMatches - Applied Matches
appliedMatchesTotal - Total Applied Matches
blockedHits - Blocked Hits
blockedHitsTotal - Total Blocked Hits
edgeProxyHits - Edge Proxy Hits
edgeProxyHitsTotal - Total Edge Proxy Hits
actionsTakenPercent - Actions Taken %
appliedMatchesPercent - Applied Matches %
hostingProviderHits - Hosting Provider Hits
hostingProviderHitsTotal - Total Hosting Provider Hits
proxyHits - Proxy Hits
proxyHitsTotal - Total Proxy Hits
redirectHits - Redirect Hits
redirectHitsTotal - Total Redirect Hits
smartDNSHits - Smart DNS Hits
smartDNSHitsTotal - Total Smart DNS Hits
torExitHits - Tor Exit Hits
torExitHitsTotal - Total Tor Exit Hits
vpnDataCenterHits - VPN Datacenter Hits
vpnDataCenterHitsTotal - Total VPN Datacenter Hits
vpnHits - VPN Hits
vpnHitsTotal - Total VPN Hits

Carbon Calculator report

The Carbon Calculator report provides detailed calculations around the amount of emissions your ​Akamai​ traffic generates while giving insight into ​Akamai​ platform emissions efficiency.

• a summary across all countries of emissions and edge bytes for the selected time range and filters,
• a time series across all countries of emissions and edge bytes for the selected time range and filters,
• total bytes and emissions by country for the selected time range and filters.
  The granularity is one day, standard 3-month retention.

Use the Carbon Calculator report

1. From the Reports menu or Reporting overview page, select the Traffic - Carbon Calculator report.
2. Select filters:
   1. Date range (required). Click the date picker icon to adjust the date and time.
   2. Groups and Properties. Narrow down your content to groups of CP codes.
   3. CP codes (required). Select CP codes.
   4. Delivery type. Optionally select secure or non-secure traffic.
   5. Country/area. Optionally select the country or area generating traffic.
3. Click Apply.
   The report loads with the following widgets:
   - the summary KPI section showing total edge bytes and total calculated emissions,
   - Calculated emissions and edge bytes in time,
   - Calculated emissions and edbe bytes by geography with a geo heatmap,
   You can switch between Edge bytes and Calculated emissions tabs to see specific data.
   - Calculated emissions and edge bytes by geography table.
4. To see more results, access the widget data through API calls:
   1. Click the API calls icon next to the widget.
   2. Copy the API call into your API tool and run.
      For general information on how the reporting API works, see Reporting API.

Filters
Select at least one required filter in every report. For optional filters, making no selection returns all associated data for that filter.

• Time and date picker. The date and time range selected for a report helps to limit data and focus on what you want.
• Groups (optional). Groups let you narrow down your content to groups of CP codes.
• Properties (optional). Properties let you narrow down your content to given property CP codes.
• CP codes. Content provider (CP) codes let you segment your delivered content for tracking and reporting purposes. All CP codes have ties to one or more services, which are tracked and reported under that CP code.
• Delivery type (optional). Distinguishes secure traffic from non-secure traffic.
• Country/area. The country or area serving traffic (served from).

Metrics

• Edge bytes. The total edge traffic volume.This includes request and response bytes as well as overhead bytes for all request types (GET-HEAD, PUT-POST)

• Calculated emissions. CO2 calculated emissions. The t unit stands for metric tonnes.

General emissions calculation disclaimer
The methodology used to calculate the carbon emissions information is believed to be accurate. However, no responsibility for either the accuracy of the information or the precision of the methodology will be assumed, and no liability for any decisions made or actions taken in reliance on the report will be accepted.

Edge emissions methodology summary
​Akamai​ has developed a methodology to attribute Greenhouse Gas Emissions (CO2e) to units of platform capacity measured against gigabytes (GB). This methodology was applied to every edge region across the ​Akamai​ Global Intelligent Platform and rolled up by country to give a detailed analysis of emissions output based on actual customer utilization. This method can calculate emissions output per GB of traffic accounted for on the platform. This granularity provides our customers visibility into their total CO2e emissions impact using ​Akamai​ Edge services globally. The emissions calculation is in line with the following globally accepted standards:

• World Resources Institute (WRI)/World Business Council for Sustainable Development (WBCSD) Greenhouse Gas (GHG) Protocol Corporate Accounting and Reporting Standard (Scope 2).
• WRI/WBCSD Greenhouse Gas Protocol Corporate Value Chain (Scope 3) Accounting and Reporting Standard (Scope 3).

Carbon emissions calculator general assumptions

• A 3rd party verifier has not audited data displayed in each customer's carbon calculator. Data is assumed to be accurate based on the data sources from our network, renewable energy production, and our clean data center partners. All reports are subject to change at any time.
• Baseline emissions factor data includes all ​Akamai​ Global Intelligent Edge network operations. The factors include hardware operations and related facility power usage effectiveness (PUE) adhering to greenhouse gas protocol Scopes 2 and 3.
• PUE is calculated using our annual colocation survey, and results are averaged across our facilities to ensure proper emissions impact is appropriately allocated.
• Data for our operations globally are broken down by network region and rolled up by country to create a unique emissions factor for each individual country.
• Our emissions reductions are translated for our customers to view the overall impact. These reductions include attributions from our renewable energy projects, data center partners, and other emissions reduction sources based on our market-based emissions for Scope 2 and extended network Scope 3 in each country.
• All emissions measurements are shown in Carbon Emissions Equivalency (CO2e)
• ​Akamai​ platform emissions factors are calculated against the most current and validated sources, including:
  • US-eGRID
  • Location Marginal Emissions (LME) - When applicable, US Only
  • International Energy Agency (IEA)
  • Australia Government Industry
  • EU AIB European Residual Mix
  • Canada ECCC National Inventory Report
  • UK DEFRA GHG Conversion Factors
• ​Akamai​ yearly emissions statement follows the ISO 14064-3 Second Edition 2019-04: Greenhouse gasses -- Part 3: Specification with guidance for the verification and validation of greenhouse gas
• Network utilization totals are pulled directly from our distributed data collected (DDC) by customer to calculate Edge traffic emissions. The traffic totals are calculated by country to provide an overall emission impact by country.

Traffic by Hostname report

The Traffic by Hostname report allows you to see key traffic stats, in near real-time, by dimensions that are relatable to your business and easy to use. The report offers edge metrics by end-user-requested hostname, which is the sub.domain.com section of the URL that an end-user types into their browser, and represents the value from the Host header.

Hostname reporting lets you:

• See log-based data in near real-time (5-10 minutes).
• Monitor the health of your applications by hostname and status code.
• Understand traffic levels by hostnames without creating extra variables.
• Determine the traffic consumed by individual hostnames (for example, brands) or groups of hostnames.

End-user requested hostname is an additional dimension of the Traffic by Hostname report. While the CP code dimension is still required for authorization purposes, you can both filter and view data by hostnames in this report. Relative to hostnames, one CP code can contain multiple hostnames, or, one hostname can contain multiple CP codes. Therefore, hostnames make it easier to understand the scope of the data presented.

📘

If multiple CP codes are assigned to a given hostname and you are authorized for a subset of them, you will only be able to see data for that hostname belonging to the CP codes that you are authorized to see.

Use the Traffic by Hostname report

1. From the Reports menu, select the Traffic by Hostname report.

2. Select filters. Recommended filters are:

   1. Date range. Click the date picker icon to adjust the date and time.
   2. Group and Property. These are parent filters for both hostnames and CP codes.
   3. Top Hostnames. You can see up to 20,000 hostnames by the hits in the last ten days. The list includes only hostnames that had at least two hits per 5 minutes, over the last 10 days. The hostname list filters results starting from hostnames with the most hits. Select specific hostnames you want to see data for. Enter keywords that match your search criteria to narrow your search.
   4. CP codes (required filter). Use the CP code filter to get a part of the traffic on a given hostname. If you select hostnames first, corresponding CP codes are selected automatically. You can use a regex filter or not filter by hostnames at all, and the report will still return data as long as CP codes are selected.
   5. Hostnames. You can narrow down results by using a regex filter or select a hostname that is not visible in the top 20,000 hostnames. The following match criteria apply: Contains, Starts with, Ends with, Does not contain, Does not start with, Does not end with, Match a regular expression, Does not match a regular expression, or Is an exact match). You can then add a Hostname pattern to match.
   6. If applicable, select other filters to meaningfully limit the report data. See the Filters section for more information.

3. Click Apply.
   The report loads with the following widgets (example given for Hits tab):

   • Average rollup (edge hits per second).
   • Maximum rollup (Edge hits).
   • Maximum rollup (Top hostnames edge hits).
   • Edge hits by hostname.
   • Average rollup (Edge hits per second by response class).
   • Edge hits by response class.
   • Edge hits by response.
   • Edge hits per second by time and HTTP version.
   • Edge hits by HTTP version.
   • Traffic segments by CP code.
     Edge traffic by hostname tables are limited in the UI to the top 5000 results. The API enables you to retrieve the top 25000 hostnames for a given selection. If you have more than 25000 hostnames, you can make multiple calls with different filters to access all of the hostnames.

4. To see results for a higher number of hostnames, access the widget data through API calls:

   1. Click the API calls icon next to the widget.
   2. Copy the API call into your API tool and run.
      For general information on how the reporting API works, see Reporting API.

📘

The Group and Property filtering option is available in the UI report only.

Filters

Group and Property (optional). Lets you narrow down your request to particular hostnames and related CP codes.

Top hostnames (optional). Hostnames from which end-users are requesting your content.

CP codes (required). Content Provider (CP) codes let you segment your delivered content for tracking and reporting purposes.

Hostnames (optional). A flexible selection for hostnames, not limited to the top hostnames in the Top hostnames filter. You can use a custom string search, using the following match criteria: Contains, Starts with, Ends with, Does not contain, Does not start with, Does not end with, Match a regular expression, Does not match a regular expression, or Is an exact match. You can also add a Hostname pattern to match. Note this filter works as an AND condition when used with other filters- including the Top Hostnames selector.

Cacheability (optional). Distinguishes cacheable content from non-cacheable content.

Delivery type (optional). Distinguishes secure traffic from non-secure traffic.

HTTP version (optional). Possible options are: HTTP, HTTPS/1.1, HTTP/2, or HTTP/3.

IP version (optional). Supported array values are IPv4 and IPv6. If no IP version is selected, the report shows data for both IPv4 and IPv6.

Traffic (optional). HTTP response traffic to be included in the report data.

• All Responses. (only available on the Bytes tab)
• PUT/POST Responses.
• GET/HEAD Responses.
• PUT/POST Requests. (only available on the Bytes tab)

📘

In addition to GET/HEAD Responses, PUT/POST Requests and PUT/POST Responses, the Hostname report Bytes metrics include GET/HEAD requests. The "Traffic" report only includes GET/HEAD Responses, PUT/POST Requests and PUT/POST Responses but excludes GET/HEAD requests.

Responses:
Response status (optional). An indicator showing successful or failed HTTP response.
Response class (optional). A class of HTTP response status codes, from 0XX through 6XX.
Response code (optional). An HTTP response status code, for example, 404.

Metrics

On the Hits tab:
Edge hits total. The total number of edge requests.
Edge hits per second max. Peak value of edge requests per second for the given interval.
Edge hits per second min. Minimum value of edge requests per second for a given interval.
Edge hits per second. The number of edge requests per second for a given interval.
Maximum edge hits. The peak edge requests for a 5 minute interval.
Edge hits. The number of edge requests.
Edge hits percent. The number of edge requests for a given dimension related to the total number of edge requests.

On the Bytes tab:
Edge bytes total. The total volume of edge traffic.
Edge bits per second max. Peak edge bandwidth value for a given interval.
Edge bits per second min. The minimum edge bandwidth value for a given interval.
Edge bits per second. The edge bandwidth for a given interval.
Maximum edge bytes. The peak edge volume for a 5 minute interval.
Edge bytes. The edge traffic volume.
Edge bytes percent. The edge traffic volume for a given dimension related to total edge volume.

Key callouts and best practices

Completeness

Completeness is defined as the percentage of logs that have been processed system-wide within a given latency. The completeness is at least at 95% within 5-10 minutes, but is not guaranteed to reach 99%.

📘

With 95% completeness, the Traffic by Hostname report should be treated as incomplete monitoring information and should not be expected to match the Traffic report or Billing invoices. Furthermore, use of Hostname data to generate financial information should acknowledge the incomplete nature of the report.

Hostname hits threshold

The Hostname report and API includes hostnames with at least two hits in any 5-minute period. After 7 days, hostnames with only one hit in any 5-minute period are aggregated into the bucket "Others", and this will appear in the hits / bytes by hostname table.

Retention

The hostname report has a retention period of 92 days, from the start of data collection. Data is available from October 7, 2022.

Hostname filter

Both UI and API currently limit the list of hostnames in the hostname filter to 20,000 objects for the last ten days, only including hostnames with at least 2 hits.

In both the UI and the API, it is not recommended to use filters to get the majority or all of the hostname data. For example, with *.com.

Data by hostname

In the UI, the Edge hits/bytes by hostname tables are limited to the top 5000 hostnames (sorted in descending order by hits or bytes). This limit is 25000 hostnames for API requests. Pagination of API results is not yet available.

New hostnames and CP codes

Being able to see data for new hostnames that have been recently added to delivery configurations depends on the CP code assigned. If an existing CP code has been assigned, data should be visible in the Traffic by Hostname report within 5-10 minutes after traffic occurred. If a new CP code is assigned, it may take up to 6 hours for data to appear while the processing system picks up an updated list of CP codes.

API rate limiting

The Hostname report API will be rate-limited at 120 requests/min per account per endpoint.

China CDN traffic

The China CDN traffic is only visible on source CP codes. China CDN specific CP codes - CP Codes that are paired with source CP codes in the CP code configuration - will not show traffic.

Best practices for retrieving hostname monitoring data

1. Retrieve monitoring data only for the latest few time buckets.
   For monitoring the health of delivery at the Edge, only data for the most recent few time buckets is sufficient. As the Traffic by Hostname data is populated in near-real time, the metrics for the older buckets are not expected to be updated. For monitoring the health of digital properties, you are encouraged to query only the last 30 minutes of data or less.
2. Avoid repeated calls to retrieve the same reporting data.
   The performance of the API or reporting system is affected by the amount of data retrieved from the data store for populating the reports. In cases where you expect to make multiple scans of the same data for analysis, we recommended that you retrieve the data once from the report API, store it in a staging database and analyze further. This approach will ensure good performance of the hostname reporting system.