私の経験も同様です。長年にわたり、非常に奇妙な小さな障害を数多く見てきました。そのため、常に完全なバックアップを維持しており、最初からやり直してサイトを復元できるようにしています。問題をその場で修正することに頼ると、最終的にはうまくいかなくなります。
あなたと同じように、Bitnamiが無料のイメージとチャートの提供を停止したとき、私は窮地に立たされました。多くのデプロイメントを適応させ、移行しなければなりませんでした。そのうちの1つが私のDiscourseデプロイメントでした。もし役に立つなら、私が非常に短時間で作成した代替Helmチャートへのリンクをここに示します（つまり、機能しますが、理想的な設計からは程遠いです）。これは、「公式のインストール方法」を使用しようとする試みです。なぜなら、これほど長い年月が経過しても「コミュニティ標準」のHelmチャートが登場するのを見ていないからです。（Bitnamiのチャートが事実上の標準だったのでしょう。なぜなら、この突然の変更を予測していた人はほとんどいなかったからです。）いずれにしても、私が1つの研究コミュニティで実行しているこの新しいチャートは、基本的に2つのコンテナを持つポッドです。公式のDocker-in-Dockerコンテナと、python:3に基づいたカスタムコンテナで、Dockerをインストールしてから公式のDiscourseインストールを使用します。すべてのコンポーネント（Discourseサーバー、Redis、PostgreSQL）が、ランチャースクリプトによってビルドされたローカルイメージのブラックボックス内で実行されるため、スケーラビリティや高可用性のサポートはありません。docker saveを使用してビルドされたイメージを永続ボリュームに保存し、local_discourse/app:latestが見つからない場合にそれをロードすることで、ポッドが別のノードで再起動する（例：OSアップデートやノードクラッシュのためにノードをドレインする場合）ことによるダウンタイムを削減することには成功しました。
しかし、あなたの質問に答えるために、この新しいデプロイメントで何かを監視する方法はわかりません。私は「本番環境」で実行していますが、私のコミュニティは十分に小さく、使用量も中程度なので、フォーラムが一時的にオフラインになっても大した問題ではありません。それでも、自己ホスティングを断念し、CommuniteqやDiscourse.orgのようなサービスに移行することに非常に近いです。