diff --git a/modules/sysadmin_guide/pages/hardware_troubleshooting_power.adoc b/modules/sysadmin_guide/pages/hardware_troubleshooting_power.adoc
index 481476e..9ff07d8 100644
--- a/modules/sysadmin_guide/pages/hardware_troubleshooting_power.adoc
+++ b/modules/sysadmin_guide/pages/hardware_troubleshooting_power.adoc
@@ -7,9 +7,8 @@ This SOP shows some of the steps required to troubleshoot and diagnose a power i
 Symptoms:
 - This server is not responding at all, and will not power on.
 - To get to mgmt of RDU2-CC devices it’s a bit trickier than IAD2. We have a private management vlan there, but it’s only reachable via cloud-noc-os01.rdu-cc.fedoraproject.org. I usually use the ‘sshuttle’ package/command/app to transparently forward my traffic to devices on that network. That looks something like: `sshuttle 172.23.1.0/24 -r cloud-noc-os01.rdu-cc.fedoraproject.org`
-
-    The devices are all in the 172.23.1 network. There’s a list of them in `ansible-private/docs/rdu-networks.txt` but this host is: `172.23.1.105`.
-    In the Bitwarden Vault, the management password can be obtained.
+- The devices are all in the 172.23.1 network. There’s a list of them in `ansible-private/docs/rdu-networks.txt` but this host is: `172.23.1.105`.
+- In the Bitwarden Vault, the management password can be obtained.
 - Logs show issues with voltages not being in the correct range.
 - At RDU2-CC we have a contact: `James Gibson`.