diff --git a/content/issues/2023-05-28-mariadb.md b/content/issues/2023-05-28-mariadb.md
index 5d2580b0..5ecf4567 100644
--- a/content/issues/2023-05-28-mariadb.md
+++ b/content/issues/2023-05-28-mariadb.md
@@ -12,12 +12,23 @@ There is a known issue with MariaDB when updating the container image to a new v
 
 MariaDB version updates (ex: `10.6.x` to `10.11.x`) can happen when updating the container image. Upgrading user databases is done manually by running a command.
 
-When the container initializes, if `MYSQL_ROOT_PASSWORD` is set an upgrade check will run. If an upgrade is required the log will indicate the need to run:
+### Recovery Procedure
 
-```shell
-mariadb-upgrade -u root -p<PASSWORD>
+If you have recently updated your container image and your container logs show repeating entries of:
+
+```log
+Caught SIGTERM signal!
 ```
 
+- Roll back the container image to a previous tag (ex: `lscr.io/linuxserver/mariadb:10.6.13` assuming this was the version you were running when things were last working)
+- Run the check, repair, analyze, and optimize commands, watch for any issues
+- Update the container image to the new tag (ex: `lscr.io/linuxserver/mariadb:10.11.3` or `lscr.io/linuxserver/mariadb:latest`)
+- Run the upgrade command
+
+This should get MariaDB running again with your user databases in a healthy state.
+
+### Check and Repair
+
 If user databases are not in a healthy state (sometimes caused by a failed upgrade), it may be remedied by running:
 
 ```shell
@@ -29,15 +40,14 @@ mariadb-check -u root -p<PASSWORD> -o -A # optimize all databases
 
 After running the above commands, you may need to run the upgrade command again.
 
-If you have recently updated your container image and your container logs show repeating entries of:
+### Upgrading
 
-```log
-Caught SIGTERM signal!
+When this container initializes, if `MYSQL_ROOT_PASSWORD` is set an upgrade check will run. If an upgrade is required the log will indicate the need stop any services that are accessing databases in this container, and then run the command:
+
+```shell
+mariadb-upgrade -u root -p<PASSWORD>
 ```
 
-- Roll back the container image to a previous tag (ex: `lscr.io/linuxserver/mariadb:10.6.13` assuming this was the version you were running when things were last working)
-- Run the check, repair, analyze, and optimize commands above, watch for any issues
-- Update the container image to the new tag (ex: `lscr.io/linuxserver/mariadb:10.11.3` or `lscr.io/linuxserver/mariadb:latest`)
-- Run the upgrade command above
+### Closing Notes
 
-This should get MariaDB running again with your user databases in a healthy state.
+If you are running MariaDB databases in production, we always recommend pinning the container image to a specific version tag, such as `lscr.io/linuxserver/mariadb:10.6.13-r0-ls97`, and planning any upgrades so that you can test and monitor them.