diff --git a/doc/source/system_configuration/kubernetes/advanced-ptp-configuration-334a08dc50fb.rst b/doc/source/system_configuration/kubernetes/advanced-ptp-configuration-334a08dc50fb.rst
index 920eab0fa..36f541e29 100644
--- a/doc/source/system_configuration/kubernetes/advanced-ptp-configuration-334a08dc50fb.rst
+++ b/doc/source/system_configuration/kubernetes/advanced-ptp-configuration-334a08dc50fb.rst
@@ -208,26 +208,26 @@ The log output for dynamically updated values can be found in
 Ts2phc Offset Spike Mitigation
 ------------------------------
 
-Ts2phc can be configured to detect and ignore intermittent offset spikes that
+``ts2phc`` can be configured to detect and ignore intermittent offset spikes that
 may result in incorrect clock adjustments. This behaviour is controlled using
 the global instance parameter ``max_phc_update_skip_cnt``. The
 ``max_phc_update_skip_cnt`` parameter is the number of consecutive offset
 spikes in a row that will be ignored. For example, setting
-``max_phc_update_skip_cnt`` to 120 would allow ts2phc to ignore 120 consecutive
+``max_phc_update_skip_cnt`` to 120 would allow ``ts2phc`` to ignore 120 consecutive
 offset spike incidents before adjusting the clock.
 
 Offset Spike Characterization
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The |prod| systems using the realtime kernel may experience an intermittent
-offset spike behaviour in ts2phc. This intermittent offset spike behaviour
-results from |GNSS| messages that take time to arrive at the userspace ts2phc
-application. The delayed |GNSS| messages can cause ts2phc application to
-calculate an incorrect adjustment value for the |PHCs|. This results in ts2phc
+offset spike behaviour in ``ts2phc``. This intermittent offset spike behaviour
+results from |GNSS| messages that take time to arrive at the userspace ``ts2phc``
+application. The delayed |GNSS| messages can cause ``ts2phc`` application to
+calculate an incorrect adjustment value for the |PHCs|. This results in ``ts2phc``
 making large adjustments to its |PHCs| and can cause unstable system time. An
 example of this behaviour can be seen in the log snippet below. If log events
 similar to the given example are observed, configuring offset spike mitigation
-in ts2phc can improve timing stability by detecting and ignoring these large
+in ``ts2phc`` can improve timing stability by detecting and ignoring these large
 offset calculations.
 
 Example:
@@ -266,10 +266,10 @@ Example:
 Configure Offset Spike Mitigation
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-The offset spike mitigation behaviour is enabled in ts2phc by default with a
+The offset spike mitigation behaviour is enabled in ``ts2phc`` by default with a
 value of ``max_phc_update_skip_cnt`` = 120.
 
-To configure the number of consecutive offset spikes that will be ignored by ts2phc, use the
+To configure the number of consecutive offset spikes that will be ignored by ``ts2phc``, use the
 following |PTP| instance parameter:
 
 .. code-block:: none
@@ -279,7 +279,7 @@ following |PTP| instance parameter:
     # Apply the configuration. This will restart all PTP services.
     system ptp-instance-apply
 
-The value 120 will allow ts2phc to ignore up to 120 consecutive offset spikes.
+The value 120 will allow ``ts2phc`` to ignore up to 120 consecutive offset spikes.
 This value may need to be adjusted based on testing and observation in your environment.
 Consecutive occurrences are not observed often, with subsequent updates
 arriving in a timely manner.