У меня есть детализированный показатель доступности сервиса выгрузки.
По существу:
• не хер знает когда, а каждые 5 мин, и каждую минутку я бегаю за результатом, точно знаю, что результат еще не был готов или заираю готовый (или ошибку). Таким образом я точно знаю, что запрос отправлен тогда-то, получен ответ тогда-то, обработка заняла столько-то, а значит, что с момента запроса до получения ответа я ровно столько-то минут ждал ответ от системы, и если этот лаг в 55 минут, я уже показываю, что выполнить своевременную блокировку новых ресурсов не мог.
• Таймаут в час и забить болт - это означает не знать результата. Есть ноль, есть единица, а есть null. Вот ты предлагаешь добавить третье состояние null — это в корне неверно, потому что результат есть всегда, а в твоем случае ты перепишешь результат своим null, чем испортишь достоверную статистику, размазав абстракцией. Само собой, у тебя не будет показателей лагуческти реестра, если запросы будут выполняться больше часа в соответствии с твоим предложением.
• ну класс, у меня 20-21 инстанс и роста нет... Где роста нет? :) У меня роста нет? :) в ЕАИС же все-равно запросы надо после таймаута новые слать по твеой задумке. То есть, если ушло 20 инстансов за последние 20*5=100 минут, то срабатывает таймаут, запросы по твоей версии протухают, и я должен слать новые, верно? То есть  в любом случае, в какой-то момент, не дождавшись ответа, я буду слать новые.
Разница лишь в том, что в твоем варианте перестаем следить за состоянием запросов старше 1 часа.

у меня сожрется? почему сожрется? я же не держу процесс в апе. Там по расписанию выполняются проверки и все

то есть это не 20 коннекшенов

это всегда 1 тред, который проворачивает шестеренки и обновляет статусы
* на самом деле не один

Ну не совсем. Примерно в это время на обсуждении было 2 НПА - один со стороны Минсвязи, которому я уделил внимание, и второй - РКНовский отрыжк, который остался без внимания. 50% КПД - это не бездействие

Да, перестаем за бессмысленностью.

а смысл есть - я буду точно знать время, которое обрабатывался запрос, а значит смогу оперировать вполне конкретными данными: не "за 60 минут ответ не был получен", а "ответ был получен лишь спустя 12 часов, равно как и все остальные, направленный в смежные периоды". То есть в одном случае мы говорим о сбоях, а во втором случае тыкаем носом, что это не просто сбой, а "время восстановления работы системы заняло столько-то времени". Или "даунтайм системы составит столько то часов в таком-то интервале", что позволит установить точный временной промежуток и надавить на РКН, чтобы те отозвали все претензии к операторам, если у них выявлены пропуски именно в этом промежутке. Улавливаешь посыл?
РКН профакапился 32 января 2016 года: в период с 15:00 до 23:00 по Московскому времени операторы не имели возможность получить выгрузку из-за сбоя в СМЭВ, который не позволял проверить ЭЦП операторов и был устранен только в 23 часа 0 минут. Неработоспособность ЕАИС отразилась на операторах связи, которые не смогли воворемя получить выгрузку и обновить свои фильтры. А так как система "Ревизор 35.0" получает данные из систем РЧЦ минуя процедуру проверки ЭЦП через СМЭВ, "Ревизоры" проверяли доступность вновь добавленных в период сбоя в выгрузку ресурсов, впоследствии были выявлены нарушения со стороны операторов в виде несоблюдения закона в части ограничения доступа к "запрещенным" ресурам.

И еще раз, вы уже позабыли, у нас даже прецедент уже был, и лишь отсутствие штрафов за этот период не вызвало хайпа

Прокурорские - сколько, час?
А выгрузка сколько не была доступна?
Надеюсь, мне удалось разжевать важность такой статистики

Это наши доводы в случае защиты. Наличие информации априори лучше ее отсутствия. Пока мы уязвимы - это просто маст хэв быть. Особенно на фоне смертельных штрафов

Дык Ревизор этот час вообще не соблюдает, эпизодически попадаю на 1-2 пропуска, логи приводил выше. Сутки -- да, а час походу туда в ТЗ не был заложен.

И да, нет в реестре отметки времени включения ресурса в выгрузку.

И когда у Генпрокуратуры пригорает активно -- они наверное прям в Ревизор пихают новые IP, а потом уже в выгрузку ;)

А так, делая запросы регулярно, можно с точностью до 5 минут установить время, начианя с которого ресурс появился в выгрузке и операторы имели возможность блокировать ресурс.

Мне метка не нужна, я лог с диффами выгрузки приводил. 15-20 минут назад там IP не было, а коробка уже зафиксировала пропуск.

И здесь важный момент:
Оператор сделал запрос на получение выгрузки в 12:00, получил ответ лишь в 14:00
По факту, в выгрузке на 12:00 ресурс уже был, но получить его оператор смог только в 14:00.
Эдакая игра "кто кого наипет"

Ну, по НПА же назначен виноватым оператор, и "нет оснований не доверять..."

И нафиг им таймстампы в Реестре -- свои косяки раскрывать? Мож сразу блокчейн? ;)

Ну не нужна тебе и ладно, а мне нужна. Просто ты довольствуешься дифом, а мне годится только обоснованная информация, то есть первоисточник, на основе которого дифф строился. Вот у тебя получается "ресурса не было", а я скажу, что он появился только во столько-то, потому что запрос отправлен тогда-то, ответ получен тогда-то и вот имеем то, что имеем. То есть дифф - это следствие событий. Если у тебя спросят а почему в дифе не было, что ты скажешь?