Дневные уведомления сайта приходят, а ночной отчёт из cron отсутствует или найден в Спаме. Проверка формы в браузере не воспроизводит эту проблему. Планировщик запускает приложение в другом контексте: могут отличаться рабочая директория, переменные окружения, версия PHP и доступ к настройкам транспорта.
Не начинайте с изменения темы отчёта. Сначала установите, что задание запустилось, сформировало нужное письмо и передало его почтовой системе. Только после этого имеет смысл исследовать папку. Иначе ошибка чтения конфигурации будет ошибочно названа решением спам-фильтра.
Отдельная полезная проверка — часовой пояс задания. Отчёт может формироваться по расписанию сервера, которое не совпадает с ожидаемым временем отдела. Это не объясняет папку Спам, но помогает правильно связать запуск с полученной копией и не принять ещё не запущенное задание за пропавшее письмо.
Разделите журнал на понятные события
Для одного запуска нужны время старта, результат выполнения, факт создания сообщения и результат передачи транспорту. Если приложение пишет только «cron выполнен», этого недостаточно. Команда могла завершиться после ошибки, создать пустой отчёт или пропустить отправку из-за условия в коде.
Не записывайте в журнал пароли SMTP, токены или полный текст отчёта с клиентскими данными. Для связи событий достаточно внутреннего идентификатора задания и, если доступен, Message-ID. Так вы сможете найти конкретную попытку, не превращая диагностику в новую копию чувствительной переписки.
Сравните CLI и веб-конфигурацию
Проверьте пользователя запуска, путь к приложению и файл конфигурации, который читает задание. Относительный путь, работающий из веб-каталога, может вести в другое место при cron. В результате SMTP-параметры не загружаются, а приложение использует запасной локальный способ или прекращает работу.
Не предполагайте такое переключение без фактов: это гипотеза для проверки. Посмотрите журнал выбранного транспорта и полученные заголовки. Если настройки совпадают, переходите дальше. Если различаются, устраните конкретное расхождение и повторите безопасный запуск только этого задания, не всей производственной очереди.
Уточните, кто отправляет служебный отчёт
Письмо самого приложения и уведомление планировщика о выводе команды — разные сообщения. У них могут быть разные отправители и адресаты. Системный вывод не обязательно проходит через SMTP-модуль сайта, даже если обычные уведомления настроены правильно.
Timeweb описывает локальную отправку PHP mail через почтовый агент хостинга и особенности технического отправителя. Если cron использует именно этот путь, его нужно проверять отдельно от SMTP-настроек CMS. Не переносите результат теста плагина на произвольную команду mail в задании планировщика.
Проверьте очереди и повторные попытки
Если приложение использует очередь, запуск cron может только создать задачу, а письмо отправляет другой процесс. Установите, какой именно этап выполнен. При временной ошибке сообщение способно остаться на повторную попытку; при постоянном отказе полезен точный ответ сервера.
Не запускайте задание многократно, пока не выяснили, создаёт ли каждый запуск новую копию отчёта. Для тестирования используйте отдельные безопасные данные и отключённые реальные получатели в предусмотренном режиме. Иначе проверка доставляемости сама создаст дубликаты уведомлений и затруднит сопоставление результатов.
Сделайте контрольный запуск тем же способом
Возьмите текущие адреса из проверки размещения Check и выполните тестовый экземпляр задания через тот же CLI-путь. Сохраните отправителя, шаблон и транспорт. При необходимости обезличьте содержимое отчёта, указав это отличие. Ручная пересылка готового HTML из веб-почты не проверит окружение cron.
Свяжите время старта, принятия сервером и обнаружения копии. Если письмо найдено в Спаме, это подтверждённое размещение. Если копии нет, проверьте статус отправки и полноту наблюдений. Unknown и No data не следует автоматически превращать в вывод о блокировке.
Сравните исправление на одном уровне
При ошибке пути исправьте путь и сохраните прежний транспорт. При несоответствии From исправьте отправителя. Если требуется переход с локальной почты на SMTP, обозначьте это как изменение маршрута, которое может затронуть подпись и исходящий сервер одновременно. Содержимое отчёта при этом оставьте сопоставимым.
Повторите запуск и запишите фактическую папку каждого доступного контрольного ящика. Успешное завершение cron не равно попаданию во Входящие, а успешная аутентификация не объясняет всё решение фильтра. Правила наблюдения и ограничения приведены в методологии Check.
Итоговая карточка задания должна содержать путь запуска, источник конфигурации, ответственный транспорт и способ безопасного повторения. Тогда проверка после изменения PHP или переноса сайта займёт один воспроизводимый сценарий, а не поиск различий между случайными письмами из браузера и планировщика.
Видео-памятка: что проверить
Видео без звука, 24 секунды. Текстовая версия краткого плана:
- Сначала подтвердите запуск задания и создание сообщения.
- CLI и веб-запрос могут использовать разную конфигурацию.
- Проверяйте письмо из планировщика, а не из браузера.