diff --git a/modules/sysadmin_guide/nav.adoc b/modules/sysadmin_guide/nav.adoc
index 1aefd62..4509e1b 100644
--- a/modules/sysadmin_guide/nav.adoc
+++ b/modules/sysadmin_guide/nav.adoc
@@ -30,7 +30,7 @@
 ** xref:fedmsg-introduction.adoc[fedmsg introduction and basics - SOP]
 ** xref:fedmsg-irc.adoc[fedmsg-irc - SOP]
 ** xref:fedmsg-new-message-type.adoc[Adding a new fedmsg message type - SOP]
-** xref:fedmsg-relay.adoc[fedmsg-relay - SOP in review ]
+** xref:fedmsg-relay.adoc[fedmsg-relay - SOP]
 ** xref:fedmsg-websocket.adoc[fedmsg-websocket - SOP in review ]
 ** xref:fedocal.adoc[fedocal - SOP in review ]
 ** xref:fedora-releases.adoc[fedora-releases - SOP in review ]
diff --git a/modules/sysadmin_guide/pages/fedmsg-relay.adoc b/modules/sysadmin_guide/pages/fedmsg-relay.adoc
index b97cb82..4a2464f 100644
--- a/modules/sysadmin_guide/pages/fedmsg-relay.adoc
+++ b/modules/sysadmin_guide/pages/fedmsg-relay.adoc
@@ -15,44 +15,42 @@ Purpose::
 
 == Description
 
-fedmsg-relay is running on app01, which is a bad choice. We should look
-to move it to a more isolated place in the future. busgateway01 would be
+_fedmsg-relay_ is running on _app01_, which is a bad choice. We should look
+to move it to a more isolated place in the future. _busgateway01_ would be
 a better choice.
 
 "Ephemeral" scripts like `pkgdb2branch.py`, the post-receive git hook on
-pkgs01, and anywhere fedmsg-logger is used all depend on fedmsg-relay.
+_pkgs01_, and anywhere _fedmsg-logger_ is used all depend on _fedmsg-relay_.
 Instead of emitting messages "directly" to the rest of the bus, they use
 fedmsg-relay as an intermediary.
 
-Check that fedmsg-relay is running by looking for it in the process
+Check that _fedmsg-relay_ is running by looking for it in the process
 list. You can restart it in the standard way with
 `sudo service fedmsg-relay restart`. Check for its logs in
 `/var/log/fedmsg/fedmsg-relay.log`
 
-Ephemeral scripts know where the fedmsg-relay is by looking for the
+Ephemeral scripts know where the _fedmsg-relay_ is by looking for the
 relay_inbound and relay_outbound values in the global fedmsg config.
 
 == But What is it Doing? And Why?
 
-The fedmsg bus is designed to be "passive" in its normal operation. A
-mod_wsgi process under httpd sets up its fedmsg publisher socket to
+The _fedmsg_ bus is designed to be "passive" in its normal operation. A
+_mod_wsgi_ process under _httpd_ sets up its _fedmsg_ publisher socket to
 passively emit messages on a certain port. When some other service wants
 to receive these messages, it is up to that service to know where
-mod_wsgi is emitting and to actively connect there. In this way,
+_mod_wsgi_ is emitting and to actively connect there. In this way,
 emitting is passive and listening is active.
 
 We get a problem when we have a one-off or "ephemeral" script that is
-not a long-running process -- a script like pkgdb2branch which is run
+not a long-running process -- a script like _pkgdb2branch_ which is run
 when a user runs it and which ends shortly after. Listeners who want
 these scripts messages will find that they are usually not available
 when they try to connect.
 
-To solve this problem, we introduced the "fedmsg-relay" daemon which is
+To solve this problem, we introduced the "_fedmsg-relay_" daemon which is
 a kind of "passive"-to-"passive" adaptor. It binds to an outbound port
 on one end where it will publish messages (like normal) but it also
 binds to an another port where it listens passively for inbound
 messages. Ephemeral scripts then actively connect to the passive inbound
-port of the fedmsg-relay to have their payloads echoed on the
+port of the _fedmsg-relay_ to have their payloads echoed on the
 bus-proper.
-
-See http://fedmsg.readthedocs.org/en/latest/topology/ for a diagram.