diff --git a/man/systemd.unit.xml b/man/systemd.unit.xml
index 20e52c5664..42dcbac72c 100644
--- a/man/systemd.unit.xml
+++ b/man/systemd.unit.xml
@@ -1037,13 +1037,13 @@
         <varname>Restart=</varname> logic.</para>
 
         <para>Note that units which are configured for <varname>Restart=</varname>, and which reach the start
-        limit are not attempted to be restarted anymore; however, they may still be restarted manually at a
-        later point, after the <replaceable>interval</replaceable> has passed. From that point on, the
-        restart logic is activated again. <command>systemctl reset-failed</command> will cause the restart
-        rate counter for a service to be flushed, which is useful if the administrator wants to manually
-        start a unit and the start limit interferes with that. Rate-limiting is enforced after any unit
-        condition checks are executed, and hence unit activations with failing conditions do not count
-        towards the rate limit.</para>
+        limit are not attempted to be restarted anymore; however, they may still be restarted manually or
+        from a timer or socket at a later point, after the <replaceable>interval</replaceable> has passed.
+        From that point on, the restart logic is activated again. <command>systemctl reset-failed</command>
+        will cause the restart rate counter for a service to be flushed, which is useful if the administrator
+        wants to manually start a unit and the start limit interferes with that. Rate-limiting is enforced
+        after any unit condition checks are executed, and hence unit activations with failing conditions do
+        not count towards the rate limit.</para>
 
         <para>When a unit is unloaded due to the garbage collection logic (see above) its rate limit counters
         are flushed out too. This means that configuring start rate limiting for a unit that is not