ночью шлюз упал, n8n всё сложил в ошибки

Дописываю конфиг, пока всё помню — утро сегодня было весёлое. Открываю n8n, а там красная лента: половина ночных воркфлоу лежит с connection refused. Полез в докер: litellm, через который у меня ходят все запросы к моделям (две внешние, одна своя тут же на сервере), в четыре утра упал на длинном стриме и ушёл в рестарт. restart: always его честно поднял за минуту, но n8n за это время успел настрелять в мёртвый порт и сложить всё в ошибки. Клиенты утром получили пустые отчёты, мне — объясняться.

Разбирался весь день по кускам. Сам виноват: знал, что n8n стартует быстрее шлюза и первые минуты долбит в ещё не поднявшийся порт, а healthcheck так и не прописал, руки не дошли. Вечером починил: healthcheck для litellm в compose, depends_on с condition: service_healthy у n8n, restart сменил на unless-stopped. Заодно в конфиге шлюза прописал fallbacks — если основная модель лежит, запрос уходит на запасную, а не падает сразу.

Вопрос к тем, кто держит похожую связку. Этого хватает, или вы ещё что-то ставите между n8n и шлюзом? И второе: чем ловите такие ночные падения? Я узнал по упавшим выполнениям утром, а хотелось бы узнавать раньше клиентов.

читаю в четыре утра и молча иду смотреть, прописан ли у меня healthcheck. спойлер: нет)

а ловить раньше клиентов — не знаю, клиенты и есть самый быстрый мониторинг