docs: fix typo in deployment-alarm-failure.md

Author: efekarakus

doc_source/deployment-alarm-failure.md

@@ -27,12 +27,12 @@ Consider the following when you use the Amazon CloudWatch alarms method on a ser
 + If you use the deployment circuit breaker and the Amazon CloudWatch alarms to detect failures, either one can initiate a deployment failure as soon as the criteria for either method is met\. A rollback occurs when you use the rollback option for the method that initiated the deployment failure\.
 + The Amazon CloudWatch alarms is only supported for Amazon ECS services that use the rolling update \(`ECS`\) deployment controller\.
 + You can configure this option by using the new Amazon ECS console, or the AWS CLI\. For more information, see [Create a service using defined parameters](create-service-console-v2.md#create-custom-service) and [create\-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html) in the *AWS Command Line Interface Reference*\.
-+ You might notice that the deployment status remains `IN_PROGRESS` for a prolonged amount of time\. The reason for this is that Amazon ECS does not change the status until it has deleted the active tdeployment, and this does not happen until after the bake time\. Depending on your alarm configuration, the deployment might appear to take several minutes longer than it does when you don't use alarms \(even though the new primary task set is scaled up and the old deployment is scaled down\)\. If you use CloudFormation timeouts, consider increasing the timeouts\. For more information, see [Creating wait conditions in a template](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-waitcondition.html) in the *AWS CloudFormation User Guide*\.
++ You might notice that the deployment status remains `IN_PROGRESS` for a prolonged amount of time\. The reason for this is that Amazon ECS does not change the status until it has deleted the active deployment, and this does not happen until after the bake time\. Depending on your alarm configuration, the deployment might appear to take several minutes longer than it does when you don't use alarms \(even though the new primary task set is scaled up and the old deployment is scaled down\)\. If you use CloudFormation timeouts, consider increasing the timeouts\. For more information, see [Creating wait conditions in a template](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-waitcondition.html) in the *AWS CloudFormation User Guide*\.
 + Amazon ECS calls `DescribeAlarms` to poll the alarms\. The calls to `DescribeAlarms` count toward the CloudWatch service quotas associated with your account\. If you have other AWS services that call `DescribeAlarms`, there might be an impact on Amazon ECS to poll the alarms\. For example, if another service makes enough `DescribeAlarms` calls to reach the quota, that service is throttled and Amazon ECS' is also throttled and unable to poll alarms\. If an alarm is generated during the throttling period, Amazon ECS' might miss the alarm and the roll back might not occur\. There is no other impact on the deployment\. For more information on CloudWatch service quotas, see [CloudWatch service quotas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_limits.htm) in the *CloudWatch User Guide*\.
 
 ## Recommended alarms<a name="ecs-deployment-alarms"></a>
 
 We recommend that you use the following alarm metrics:
 + If you use an Application Load Balancer, use the `HTTPCode_ELB_5XX_Count` and `HTTPCode_ELB_4XX_Count` Application Load Balancer metrics\. These metrics check for HTTP spikes\. For more information about the Application Load Balancer metrics, see [CloudWatch metrics for your Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html) in the *User Guide for Application Load Balancers*\.
 + If you have an existing application, use the `CPUUtilization` and `MemoryUtilization` metrics\. These metrics check for the percentage of CPU and memory that the cluster or service uses\. For more information, see [Using CloudWatch metrics](cloudwatch-metrics.md#enable_cloudwatch)\.
-+ If you use Amazon Simple Queue Service queues in your tasks, use `ApproximateNumberOfMessagesDelayed` Amazon SQS metric\. This metric checks for number of messages in the queue that are delayed and not available for reading immediately\. For more information about Amazon SQS metrics, see [Available CloudWatch metrics for Amazon SQS](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-available-cloudwatch-metrics.html) in the *Amazon Simple Queue Service Developer Guide*\.
++ If you use Amazon Simple Queue Service queues in your tasks, use `ApproximateNumberOfMessagesDelayed` Amazon SQS metric\. This metric checks for number of messages in the queue that are delayed and not available for reading immediately\. For more information about Amazon SQS metrics, see [Available CloudWatch metrics for Amazon SQS](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-available-cloudwatch-metrics.html) in the *Amazon Simple Queue Service Developer Guide*\.