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 is being discontinued

This report is deprecated and will be deactivated on November 5, 2025. As an alternative, use the Traffic by Hostname 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.

If you use China CDN and want to monitor the offload metrics, use the Traffic by Hostname report.

📘

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 percentage of edge requests that were served without a corresponding origin request for given objects and filters.

• Average hits offload. The average percentage of edge requests that were served without a corresponding origin request for given objects and filters

• Maximum hits offload. The peak percentage of edge requests that were served without a corresponding origin request for given objects and filters.

• Minimum hits offload. The lowest percentage of edge requests that were served without a corresponding origin request 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

🚧

The Today's Traffic report is being discontinued

This report is deprecated and will be deactivated on November 5, 2025. As an alternative, use the Traffic by Hostname 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.

If you use China CDN and want to monitor the offload metrics, use the Traffic by Hostname report.

📘

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 percentage of edge requests that were served without a corresponding origin request for given objects and filters.

• Average hits offload. The average percentage of edge requests that were served without a corresponding origin request for given objects and filters.

• Maximum hits offload. The peak percentage of edge requests that were served without a corresponding origin request for given objects and filters.

• Minimum hits offload. The lowest percentage of edge requests that were served without a corresponding origin request 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 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 is being discontinued

This report is deprecated and will be deactivated on July 10, 2025. As an alternative, use the Carbon Calculator 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.

Known issues

A recent development of HTTP Client Hints for Google Chrome and Microsoft Edge browsers introduced Client Hints request headers. A server can use them to retrieve information from a client about devices, networks, users, and user-agent-specific preferences. Currently, ​Akamai​ reports get OS and browser data through User Agents reported by the browsers. This is why you may observe inconsistency in Traffic by Browser and OS reports for users with Chrome and Microsoft Edge browsers. We recognize this limitation and look forward to a solution. The change to extract the browser and OS details from the Client Hints response headers and include them in the Traffic by Browser and OS report is set to happen later in the year 2024.

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 for either edge hits or origin hits. 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 the report. This explains why you may observe differences between URL responses and URL traffic reports.

A cache-key is the only thing stored for a given object, post-request. This means that if the cache-key setting is set to origin hostname within an origin behavior for the CP code you're reporting on, the report will show the origin hostname rather than the end-user-requested hostname.

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 percentage of edge requests that were served without a corresponding origin request for given objects and filters.

• Maximum hits offload. The peak percentage of edge requests that were served without a corresponding origin request for given objects and filters.

• Minimum hits offload. The lowest percentage of edge requests that were served without a corresponding origin request 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 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.

• 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 for either edge hits or origin hits. 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 triggers 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.

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.
• total hits by country for the selected time range and filters.

The granularity is one day. The data retention is 13 months.

This report gives you the usage traffic by hits and bytes for all ​Akamai​ products served from a designated server location. If multiple products are assigned to a selected CP code, it is not possible to filter data by a single product only. For example, you can't show data for API Acceleration only.

Use the Carbon Calculator report

1. From the Reports menu or Reporting overview page, select the Traffic - Carbon Calculator report.
2. Select filters:
   • Date range (required). Click the date picker icon to adjust the date and time.
   • Groups and Properties. Narrow down your content to groups of CP codes.
   • CP codes (required). Select CP codes.
   • Delivery type. Optionally select secure or non-secure traffic.
   • 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, hits, and total calculated emissions.
   • Calculated emissions and edge bytes.
   • Edge hits.
   • Calculated emissions, edge bytes, and edge hits by geography map. You can switch between Calculated emissions, Edge bytes, and Edge hits tabs to see specific data.
   • Calculated emissions, edge bytes, and edge hits 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 the Reporting API v2.

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.

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

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 requested hostname, which is the domain in the hostname section of the URL and represents the value in the Host HTTP request  header. The edge metrics also include traffic for edge servers auto-managed by ​Akamai​ products, for example MSL origin hostnames.

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.

With the Traffic by Hostname report, you can:

• Monitor midgress, origin, and offload metrics.
• View max and min KPIs reflecting 5 minute peaks and lows.
• See data on coherent visualizations for Hits and Bytes tabs.
• Filter bytes by GET/HEAD requests.
• See annotations on activating and deactivating Property Manager configurations.

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. Groups and Properties. 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 the Hits tab):

   • Average rollup (Edge, midgress and origin hits/sec with offload).
   • Maximum rollup (Edge, midgress, and origin hits).
   • Maximum rollup (Top hostnames edge hits).
   • Edge, midgress, and origin hits by hostname with offload.
     Edge traffic by hostname tables are limited in the UI to the top 5000 results. The API enables you to retrieve the top 50000 hostnames for a given selection. If you have more than 50000 hostnames, you can make multiple calls with different filters to access all of the hostnames.
   • Average rollup (Edge hits per second by response class/response). To see a widget for the average rollup by response, select a response code in filters.
   • Average rollup (Origin hits per second by response class/response). To see a widget for the average rollup by response, select a response code in filters.
   • Edge and origin hits by response class.
   • Edge and origin hits by response.
   • Average rollup (Edge hits per second by HTTP version).
   • Edge hits by HTTP version.
   • Traffic segments.

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

📘

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

Apart from the report data, the time series graphs show configuration events from Property Manager. See the Events pane next to the graph for details on activating and deactivating properties.

Filters

• Groups and Properties (optional). Let 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.
• Content type (optional). Content type and subtype for the delivered media. The following content types and subtypes are reported: text/css, text/html, image/jpeg, application/json, audio/mpeg, video/mpeg, text/xml, font, application, text, image, video, audio, model, multipart, and - (other type). The data is available since February 13, 2025.
• 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:
  • HTTP method:
    • PUT/POST
    • GET/HEAD
  • Traffic direction (only available on the Bytes tab):
    • Request
    • Response

📘

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 plus Other.
  • 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 a 5 minute interval.
• Edge hits per second min. Minimum value of edge requests per second for a 5 minute 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.
• Origin hits total. The total number of origin requests.
• Origin hits per second max. Peak value of origin requests per second for a 5 minute interval.
• Origin hits per second min. Minimum value of origin requests per second for a 5 minute interval.
• Origin hits per second. The number of origin requests per second for a given interval.
• Maximum origin hits. The peak requests for a 5 minute interval.
• Origin hits. The number of origin requests.
• Origin hits percent. The number of origin requests for a given dimension related to the total number of origin requests.
• Midgress hits total. The total number of midgress requests.
• Midgress hits per second max. Peak value of midgress requests per second for a 5 minute interval.
• Midgress hits per second min. Minimum value of edge requests per second for a 5 minute interval.
• Midgress hits per second. The number of midgress requests per second for a given interval.
• Maximum midgress hits. The peak midgress requests for a 5 minute interval.
• Midgress hits. The number of midgress requests.
• Hits offload. The percentage of edge requests that were served without a corresponding origin request for given objects and filters.
• Average hits offload. The percentage of edge requests that were served without a corresponding origin request for given objects and filters.
• Maximum hits offload. The peak percentage of edge requests that were served without a corresponding origin request for given objects and filters.
• Minimum hits offload. The lowest percentage of edge requests that were served without a corresponding origin request for given objects and filters.

On the Bytes tab:

• Edge bytes total. The total volume of edge traffic.
• Edge bits per second max. Peak edge bandwidth value for a 5 minute interval.
• Edge bits per second min. The minimum edge bandwidth value for a 5 minute 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.
• Origin bytes total. The total volume of origin traffic.
• Origin bits per second max. Peak origin bandwidth value for a 5 minute interval.
• Origin bits per second min. The minimum origin bandwidth value for a 5 minute interval.
• Origin bits per second. The origin bandwidth for a given interval.
• Maximum origin bytes. The peak origin volume for a 5 minute interval.
• Origin bytes. The edge traffic volume.
• Origin bytes percent. The origin traffic volume for a given dimension, related to total origin volume.
• Midgress bytes total. The total volume of midgress traffic.
• Midgress bits per second max. Peak midgress bandwidth value for a 5 minute interval.
• Midgress bits per second min. The minimum midgress bandwidth value for a 5 minute interval.
• Midgress bits per second. The midgress bandwidth for a given interval.
• Maximum midgress bytes. The peak midgress volume for a 5 minute interval.
• Midgress bytes. The midgress traffic volume.
• Bytes offload. The volume of traffic served by ​Akamai​ that did not require hits on your origin.
• Average bytes offload. The average percentage of edge data that was served without a corresponding origin fetch.
• Maximum bytes offload. The peak percentage of edge data that was served without a corresponding origin fetch.
• Minimum bytes offload. The lowest percentage of edge data that was served without a corresponding origin fetch.

Key callouts and best practices

The Traffic by Hostname report doesn't include data for EdgeKV product.

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.

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 50000 hostnames for API requests. You can use the pagination feature to retrieve the data.

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

Read about the API rate limiting.

Edge bytes are reported differently from the old Traffic report

The Traffic by Hostname report logs response and request bytes, while the legacy Traffic report logs response bytes and PUT/POST request bytes only. We are working to align billing and reporting data and resolve this gap by the end of Q3, 2025.

The legacy Traffic report does not include GET/HEAD requests by default, whereas the Traffic by Hostname report does. To address this, we plan to introduce a filter option by Q3, 2025 that will allow you to exclude GET/HEAD requests in the Traffic by Hostname report, making it more comparable to the Traffic report.

Requests for hostnames auto-managed by ​Akamai​ products are reported as edge traffic

The Traffic by Hostname report includes requests for all hostnames, including edge servers auto-managed by ​Akamai​ products, such as MSL origin hostnames. When edge servers make requests to such auto-managed hostnames, the report shows them as edge hits. Use the Custom string search to include or exclude specific hostname traffic.

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.