How activation works

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).

Exceptions

Activations take about an hour for the following scenarios:

Cancel activations

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.

Progress tracking

โ€‹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.

Activation stages

StageDescription
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.

Fast Fallback

โ€‹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.

Limitations

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.

Error rate limit

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 2xx hits to total hits drops below 90%.

  • The ratio of 2xx and 3xx hits to total hits drops below 90%.

  • The ratio of 4xx and 5xx errors 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 4xx and 5xx errors or a decrease in 2xx and 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.


Did this page help you?