Update concepts-high-availability.md

Acrolinx fixes

Author: Jill Grant

articles/postgresql/single-server/concepts-high-availability.md

@@ -65,14 +65,14 @@ Here are some failure scenarios and how Azure Database for PostgreSQL automatica
 | ---------- | ---------- |
 | **Database server failure** | If the database server is down because of some underlying hardware fault, active connections are dropped, and any inflight transactions are aborted. A new database server is automatically deployed, and the remote data storage is attached to the new database server. After the database recovery is complete, clients can connect to the new database server through the Gateway. <br /> <br /> The recovery time (RTO) is dependent on various factors including the activity at the time of fault such as large transaction and the amount of recovery to be performed during the database server startup process. <br /> <br /> Applications using the PostgreSQL databases need to be built in a way that they detect and retry dropped connections and failed transactions.  When the application retries, the Gateway transparently redirects the connection to the newly created database server. |
 | **Storage failure** | Applications do not see any impact for any storage-related issues such as a disk failure or a physical block corruption. As the data is stored in three copies, the copy of the data is served by the surviving storage. Block corruptions are automatically corrected. If a copy of data is lost, a new copy of the data is automatically created. |
-|**Compute failure** | Compute failures are rare events. In the event of compute failure a new compute container is provisioned and the storage with data files is mapped to it, PostgreSQL database engine is then brought online on the new container and gateway service ensures transparent failover without any need of  application changes. Please also note that compute layer has built in Availability Zone resiliency and a new compute is spin up in different Availability zone in the event of AZ compute failure.
+|**Compute failure** | Compute failures are rare events. In the event of compute failure a new compute container is provisioned and the storage with data files is mapped to it, PostgreSQL database engine is then brought online on the new container and gateway service ensures transparent failover without any need of  application changes. Please also note that compute layer has built in Availability Zone resiliency and a new compute is spun up in different Availability zone in the event of AZ compute failure.
 
 Here are some failure scenarios that require user action to recover:
 
 | **Scenario** | **Recovery plan** |
 | ---------- | ---------- |
 | **Region failure** | Failure of a region is a rare event. However, if you need protection from a region failure, you can configure one or more read replicas in other regions for disaster recovery (DR). (See [this article](./how-to-read-replicas-portal.md) about creating and managing read replicas for details). In the event of a region-level failure, you can manually promote the read replica configured on the other region to be your production database server. |
-| **Availability zone failure** | Failure of a Availability zone is also a rare event. However, if you need protection from a Availability zone failure, you can configure one or more read replicas or consider using our [Flexible Server](../flexible-server/concepts-high-availability.md) offering which provides zone-redundant high availability. 
+| **Availability zone failure** | Failure of an Availability zone is also a rare event. However, if you need protection from an Availability zone failure, you can configure one or more read replicas or consider using our [Flexible Server](../flexible-server/concepts-high-availability.md) offering which provides zone-redundant high availability. 
 | **Logical/user errors** | Recovery from user errors, such as accidentally dropped tables or incorrectly updated data, involves performing a [point-in-time recovery](./concepts-backup.md) (PITR), by restoring and recovering the data until the time just before the error had occurred.<br> <br>  If you want to restore only a subset of databases or specific tables rather than all databases in the database server, you can restore the database server in a new instance, export the table(s) via [pg_dump](https://www.postgresql.org/docs/11/app-pgdump.html), and then use [pg_restore](https://www.postgresql.org/docs/11/app-pgrestore.html) to restore those tables into your database. |