diff --git a/src/content/blog/ha-alertmanager-kubernetes.mdx b/src/content/blog/ha-alertmanager-kubernetes.mdx
index df5a38e..8e1bb7d 100644
--- a/src/content/blog/ha-alertmanager-kubernetes.mdx
+++ b/src/content/blog/ha-alertmanager-kubernetes.mdx
@@ -116,7 +116,7 @@ echo Finding Alertmanager IPs...
 AM_IPS=$(jq '.items[].status.podIP' /tmp/peers.json -r)
 
 echo Generating CLI flags for Alertmanager...
-PEER_ARGS=$(echo $AM_IPS | sed 's/ /\n/g' | awk '{ print "--cluster.peer="$1":9094" }')
+PEER_ARGS=$(echo $AM_IPS | awk -v RS=' ' -v ORS=' ' '{ print "--cluster.peer="$1":9094" }')
 
 echo Writing CLI flags to /tmp/peers...
 echo $PEER_ARGS > /tmp/peers
@@ -399,4 +399,8 @@ High availability is a critical part of any production system, and the alerting
 
 AlertManager is a great solution to alerting for small-to-medium sized projects, hopefully as you can see it's not too difficult to make it highly available as well.
 
+A couple of things you might want to consider to improve on this solution would be:
+- Building/locating an Alpine image with `jq` and `curl` preinstalled to speed up the init container
+- Looking at other affinity rules to ensure distribution of your workload if you wish to separate on factors other than node hostname
+
 If you have any questions or comments, feel free to reach out to me over email at [joe@jb3.dev](mailto:joe@jb3.dev) or on Twitter at [@JoeBanksDev](https://twitter.com/JoeBanksDev).