Установить причину обычно можно, если сохранились следы события: журналы приложения и сервера gunicorn или uvicorn за нужный период, записи об ошибках со стеком вызовов, измеряемые показатели работы, сведения о нагрузке и о версии, которая работала в это время. По ним эксперт восстанавливает временную шкалу и находит, где именно уходило время или что привело к отказу.
Дальше проверяем альтернативные объяснения — это главная часть работы: код, настройки, выросший объём данных, поведение смежной системы, ограничения памяти и процессора. Со стороны базы данных смотрят планы выполнения запросов, журнал медленных запросов и блокировки. Для Python добавляется ещё одна проверка: не изменилось ли поведение из-за обновления библиотеки или версии интерпретатора, — поэтому эксперт разворачивает стенд с теми же версиями.
Учтите, что «медленно» — не техническая категория, пока не назван измеримый критерий: какая операция, при каком объёме данных, за какое время и по какому пункту требований. Если такого критерия в договоре нет, эксперт описывает фактические показатели и их причины, а вывод о нарушении обязательств делает суд.