Activation propagates your configuration settings across the edge servers on Akamai's production and staging networks. The time it takes to complete activations is usually about 15 minutes on production and 3 minutes on staging.
Activation times can vary depending on the state of your property. See Exceptions.
To activate a property version, see Activate your property.
Activation is also available through Property Manager API (PAPI).
Activations take about an hour for the following scenarios:
First time activations for new properties.
Property versions where a hostname was added or removed. The new version has different hostname information than the property version that is currently active on the network.
The time it takes to cancel activations on Akamai's staging or production network varies depending on the state of your property:
If your property doesn't fall under exceptions, you may cancel an activation at any time before it's complete. The last active version will be restored on Akamai's network.
If your property does fall under exceptions, there is a limited time in which you may cancel the activation. The cancel button becomes inactive after that time, in which case the activation continues for that property version. If you cancel the activation, the roll-out process never begins and the currently active version remains active.
If you miss the cancellation window, and still want to fall back to the previous version, wait for the activation of that version to complete. Once the version is active, return to the Property Details page, select the active version to which you want to revert, and activate it.
Akamai uses a phased approach to propagate your property's configuration changes through the network to ensure complete safety and reliability. The process takes just a few minutes.
First, your changes are prioritized and deployed on the portion of Akamai's network serving your traffic, so you can start validating changes within minutes after you begin the activation. As you continue your work, in the background Akamai deploys your change over the entire network, and then runs the safety checks. If the system detects a problem that could affect your site, it automatically cancels the activation and lets you know.
The enhanced tracking bar shows each stage of the process and the time left before the whole activation is complete. This gives you the benefit of monitoring our background tasks, so you can go about your workflows based on your preferences.
|1 (Live)||Deploying the property version to the Akamai edge servers currently serving your traffic. After this stage is complete, you can begin testing API metrics and validating updates on your Dashboard.|
|2 (Fully Deployed)||Completing deployment to Akamai's network. After this stage, your updates are on the entire global Akamai network and you can continue testing and validating your site. For testing on staging, follow these instructions.|
|3 (Completed)||Performing safety checks on this property version to ensure your updates are successful before completing the activation (see Error Rate Limit). If the system detects a problem, the property automatically rolls back to the last active version in about 3 minutes. Most active users are restored in under a minute.|
Akamai recognizes your need to continuously test and validate multiple changes in your environment. After the activation is complete, you have a one-hour window to revert (fall back) the configuration to your most recent active property version in under a minute.
As an example, let's say you just went live with version
4 of your property configuration on Akamai network. Next, you activated version
5 with some caching updates. Within a few minutes of version
5 going active, you notice something looks off with your metrics. The last change in your environment was this configuration update. Fast Fallback lets you quickly revert to your last active property configuration and determine whether it's the Akamai configuration update that's causing the issue, or something else happened and you need to troubleshoot further.
If you miss the one-hour window, and want to revert to a previously active version, return to the Property Details page, select the active version to which you want to revert, and activate it.
When using Fast Fallback, the following limitations apply:
Versions that fall under exceptions are not eligible for Fast Fallback and can't be selected for Fast Fallback.
Versions from which Fast Fallback was initiated can't be selected twice for this option.
You need to successfully activate at least one version between any successive Fast Fallback executions.
For properties that don't fall under exceptions, the error rate limit applies. It is a set of thresholds for HTTP errors and traffic that, if reached, can cancel the activation.
Activation can be canceled if:
The ratio of successful
2xxhits to total hits drops below 90%.
The ratio of
3xxhits to total hits drops below 90%.
The ratio of
5xxerrors to total hits increases by more than 10 times.
These checks detect extreme changes, such as traffic greater than 1000 hits per second on average, and are meant to minimize false positives. The thresholds are reached if your entire site is about to get Denial of Service (DoS) on activation, but not for isolated or low volume error conditions, that is fewer than 1000 hits per second on average.
If the activation of a new version leads to a significant increase in
5xx errors or a decrease in
3xx responses, the property automatically rolls back to the previously active version. You get notified if this happens. If the change in errors or traffic is expected, you can deselect Cancel Activation if Error Rate Increases to bypass the error rate check, and then activate the version again. You can also fix any mistakes in the configuration and activate again later.
Don't deactivate this additional safety feature unless you expect a significant increase in the error rate and are prepared for it.
The examples where an increase in error rate is expected include:
Turning on Web Application Firewall (WAF) to block potentially malicious traffic.
Adding geo-blocking to prevent access by some countries, states or provinces.
Adding any other type of access control settings that result in denying access to some subset of traffic. For example, referrer checking.
Updated 3 months ago