diff --git a/README.md b/README.md
index 659d1b7c306aeb7dfda9fb629f93bb624de3b628..d3c58bc931a709c9b5a344050fc205d34233c1ef 100644
--- a/README.md
+++ b/README.md
@@ -8,7 +8,7 @@
         - [Single Deployment](#single-deployment)
         - [Redundant Deployment](#redundant-deployment)
             - [Managing Active Engine State](#managing-active-engine-state)
-            - [High Availability Playlog Synchronization](#high-availability-playlog-synchronization)
+            - [Playlog Synchronization for High Availability deployment scenarios](#playlog-synchronization-for-high-availability-deployment-scenarios)
                 - [Active Sync](#active-sync)
                 - [Passive Sync](#passive-sync)
     - [Getting started](#getting-started)
@@ -83,7 +83,7 @@ the active engine state to the *Sync Node*.
 > In your live deployment you might not want to expose the API directly on the web. For security reasons it's highly recommended to guard it using something like NGINX,
 acting as a reverse proxy to shield your API.
 
-#### High Availability Playlog Synchronization
+#### Playlog Synchronization for High Availability deployment scenarios
 
 Usually when some new audio source starts playing, AURA Engine logs it to its local Engine API instance via some REST call. Now, the *Local API server* stores this information in its
 local database. Next, it also performs a POST request to the *Synchronization API Server*. This *Sync Node* checks if this request is coming from the currently active engine instance.