Alertas del flujo de trabajo del portal enfocado

Actualizado el 12 de agosto de 2026.

Propósito

La VM del portal ejecuta un monitor de estado sin contenido para los flujos de trabajo de diapositivas de sermones y transcripción de servicios. Complementa el historial de auditoría SQL y los registros de systemd del portal; no reemplaza ninguna de las fuentes de detalles de diagnóstico.

El monitor verifica cada cinco minutos y alerta solo después de que la misma condición esté presente en dos verificaciones consecutivas. Envía un mensaje agregado de interrupción, desduplica la condición mientras permanece activa y envía un mensaje de recuperación después de que se resuelve.

Las verificaciones de sermones filtran cada ejecución, evento y notificación a través del source_environment de confianza de la carga. Los incidentes de producción no pueden ser abiertos por una carga de desarrollo, y los incidentes de desarrollo no pueden suprimir ni satisfacer una recuperación de producción. Los trabajos de transcripción son un corpus único respaldado por producción. El monitor de desarrollo es solo para sermones; el monitor de producción es responsable de las verificaciones de trabajos de transcripción, temporizadores y grupos de Mac.

Las alertas de desarrollo van a cgood@riveroaks.org. Las alertas de producción van a productionstaff@riveroaks.org. WORKFLOW_ALERT_TO puede anular explícitamente el destinatario en un archivo de entorno protegido. Nunca coloque anulaciones de destinatarios, credenciales de MailerSend, credenciales de base de datos, claves SSH o sus valores en Git.

El canal de notificación es parte de la preparación del servicio. Cada intento de entrega registra solo el nombre del proveedor, el estado HTTP o el código de error limitado, y el recuento de destinatarios en el registro de systemd. Nunca registra un token, dirección, cuerpo o respuesta del proveedor. Un incidente procesable permanece pendiente hasta que se acuse recibo de su mensaje de interrupción o recuperación. Si MailerSend no está disponible, el punto final público de preparación de sermones no estará disponible, de modo que la ruta independiente de Uptime Kuma aún pueda notificar a los operadores.

Condiciones monitoreadas

Las verificaciones de diapositivas de sermones cubren:

cualquier servicio de extracción, entrega de tercio inferior o notificación que no esté en ejecución;
directorios protegidos de caché y salida de ProPresenter que faltan, son de solo lectura o no pueden completar una prueba atómica de escritura y sincronización;
almacenamiento del portal al 85% de uso o menos de 5 GiB libres como advertencia, y al 95% de uso o menos de 1 GiB libre como condición crítica;
configuración faltante del proveedor de notificaciones;
un ejecutable de LibreOffice faltante o un espacio de trabajo de conversión de notas de sermón protegido inutilizable (el monitor no inicia LibreOffice);
reglas de destino activas, límites de ajuste, claves de tema, archivos de plantilla inmutables o valores SHA-256 de plantilla inválidos o ausentes;
pérdida de la capacidad de la cuenta de servicio para agregar archivos debajo de cualquier destino de Google Shared Drive activo;
el receptor restringido, el destino escribible y el espacio libre en las Mac de gráficos de transmisión y diapositivas de adoración;
una etapa de procesamiento reciente o una implementación de computadora que falló y no tiene un evento exitoso posterior para la misma etapa;
una carga actual esperando un mapeo de tema de serie de sermones;
una carga actual cuya entrega de gráficos de transmisión se pospone porque la entrega está deshabilitada;
un proceso de ejecución que permanece activo más allá del umbral de estancamiento configurado;
un proceso terminal que no envió sus notificaciones de finalización tanto al cargador como al personal de producción;
una exportación de rastreo de sermón que agota su presupuesto de reintentos limitado o permanece sin entregar más allá de la ventana de ejecución estancada. Esta condición protege la evidencia de diagnóstico pero no cambia la preparación del procesamiento de sermones.

Las verificaciones ordinarias son intencionalmente económicas y no abren ProPresenter, importan una presentación, modifican una lista de reproducción, crean carpetas de Drive ni tocan archivos de sermón. Se requieren dos fallas consecutivas antes de enviar una alerta ordinaria. Las advertencias y fallas conservan una clave de incidente hasta la recuperación, por lo que una interrupción de dependencia persistente no genera correos electrónicos repetidos.

Los objetivos operativos iniciales son la detección medible y los objetivos de recuperación, no un porcentaje de disponibilidad no medido:

Señal	Objetivo
Pérdida del portal, PHP o estado del monitor	Uptime Kuma detecta en aproximadamente 3 minutos (intervalo de 60 segundos más dos reintentos)
Fallo de dependencia ordinario	Alerta enfocada en 10 minutos (dos verificaciones de cinco minutos)
Recuperación después de la reparación	Aviso de recuperación y actualización del estado público en 5 minutos
Preparación profunda	Se ejecuta a las 5:00, 11:00, 17:00 y 23:00 de lunes a sábado, más las 5:00 del domingo; más de 30 horas es crítico
Canary diario de deck real	Se ejecuta cerca de las 03:15 con fluctuación limitada; una falla, estado faltante/inválido o resultado de más de 30 horas alerta inmediatamente

Revise las marcas de tiempo reales de incidentes y recuperaciones antes de adoptar un SLO formal de disponibilidad mensual. No reclame un porcentaje de tiempo de actividad que estos datos aún no hayan medido.

Preparación profunda de sermones

Producción también ejecuta riveroaks-sermon-readiness-production.timer a las 5:00, 11:00, 17:00 y 23:00 de lunes a sábado, más las 5:00 del domingo. Su canary no mutante realiza tres verificaciones más profundas:

El portal genera una pequeña presentación sintética de punto y Escritura con el generador real, el entorno de Python anclado, el descriptor de protobuf, el primer tema inmutable activo válido y los límites de ajuste de ese tema. La salida y el manifiesto deben preservar el contenido, los recuentos, el SHA-256 de la plantilla y el SHA-256 de la salida. Todos los archivos temporales se eliminan cuando finaliza la verificación.
El receptor de gráficos de transmisión inicia ProPresenter solo cuando no estaba en ejecución, verifica que la API identifique la versión exacta de la aplicación configurada después del intervalo de calentamiento, confirma al menos un tema compatible, resuelve la biblioteca configurada y confirma que la ranura de lista de reproducción administrada aún apunta a la última presentación confirmada. No importa nada y no cambia ningún elemento de la lista de reproducción. ProPresenter se cierra solo cuando el canary lo inició.
Cuando la verificación NLT con licencia está habilitada, el portal valida la configuración privada de API.Bible y realiza una búsqueda de pasajes limitada a través de la misma caché y ruta FUMS utilizada por el procesamiento de sermones. Las verificaciones normales de cinco minutos validan la configuración sin consumir una llamada de pasaje. La falla del proveedor alerta a producción antes de que una carga y el procesamiento utilicen la opción de respaldo conservadora de referencia y significado NIV hasta la recuperación.

Cada verificación normal de cinco minutos también verifica que los límites de carga y POST de PHP del ámbito de la ruta del sermón puedan aceptar la solicitud del navegador segura de Cloudflare configurada. upload_runtime_limit_invalid es un incidente de configuración: corrija los límites de la ruta antes de la próxima carga del pastor. La página de carga verifica de forma independiente los valores activos de PHP y se niega a presentar un formulario utilizable mientras sean menores que el límite anunciado.

Una falla profunda alerta inmediatamente. El monitor de cinco minutos conserva el último resultado profundo; un resultado faltante o uno de más de 30 horas es en sí mismo crítico. Esto detecta un lanzamiento de ProPresenter roto, una API, un catálogo de temas, una biblioteca, un mapeo de lista de reproducción, un generador o un proveedor de Escrituras con licencia antes de la próxima carga del pastor.

El canary diario separado de deck real ejercita la extracción, la generación determinista, la importación de ProPresenter, la representación completa de miniaturas, la recuperación del paquete de vista previa y su informe aislado sin cambiar la lista de reproducción semanal en vivo ni contactar a los pastores o al personal de producción. Cada ejecución del monitor de cinco minutos verifica que su temporizador esté habilitado y activo antes de leer el resultado atómico. Un temporizador detenido, o un resultado fallido, faltante, inválido o con más de 30 horas, es un incidente sistémico de disponibilidad de sermones con un umbral de una verificación, por lo que el correo electrónico enfocado y las rutas /health/sermon-slides.php/Uptime Kuma coinciden. Utilice el trabajo protegido accept_sermon_daily_canary_production de GitLab para la aceptación de producción de cierre por falla; una aceptación fallida deja su temporizador deshabilitado y, por lo tanto, alerta en la próxima verificación del monitor.

La verificación profunda no mutante no afirma probar que ProPresenter puede conservar un nuevo valor de lista de reproducción: una PUT de lista de reproducción sin cambios se optimiza sin una escritura en disco, mientras que cambiar la lista de reproducción en vivo del domingo para un canary es inseguro. El incidente de agosto de 2026 demostró este límite. Hasta que se proporcione una lista de reproducción canary aislada separada, la persistencia se verifica durante cada implementación real con un reconocimiento en disco de 90 segundos y códigos de error exactos de API frente a almacenamiento. Uptime Kuma puede advertir antes de una carga para el lanzamiento, la API, el mapeo, el tema, la biblioteca, el trabajador, Drive, el almacenamiento y los fallos de estado del monitor; no puede preanunciar un defecto en la ruta de escritura que solo existe al cambiar la lista de reproducción en vivo.

Después de reparar una condición de preparación profunda, ejecute el servicio de producción una vez para que los operadores no esperen hasta la mañana siguiente para recibir la recuperación:

sudo systemctl start riveroaks-sermon-readiness-production.service
systemctl status riveroaks-sermon-readiness-production.service --no-pager

El servicio registra el nuevo resultado limitado en el mismo estado protegido y envía el aviso de recuperación desduplicado normal. No borre el JSON del incidente manualmente.

Las verificaciones de transcripción de servicios cubren:

una falla reciente del trabajo de transcripción terminal;
un arrendamiento expirado que todavía está marcado como arrendado o en procesamiento;
un temporizador de transcripción deshabilitado o un temporizador cuyo último disparador está fuera de la ventana de frescura;
cualquiera de las Mac configuradas se vuelve no disponible; si ambas no están disponibles, la alerta se resume como una interrupción completa del grupo de trabajadores.

Estas condiciones de transcripción se ejecutan solo en el monitor de producción. La unidad de desarrollo establece WORKFLOW_ALERT_TRANSCRIPTS_ENABLED=0 porque su temporizador de aceptación está instalado pero deshabilitado y ambos entornos inspeccionan la misma cola. La unidad de producción establece explícitamente el indicador en 1 y verifica el servicio y el temporizador de transcripción de producción.

Las fallas de la base de datos y las tablas de flujo de trabajo faltantes son fallas del monitor y se informan por separado. Las alertas contienen solo el entorno, los códigos de error limitados, los recuentos, la guía de remediación segura y los enlaces seguros del portal. Las fallas de intentos de reintento se desduplican por carga, por lo que una carga no abre un incidente separado para cada UUID de ejecución. No contienen texto de sermón, texto de transcripción, nombres de archivo, rutas, cuerpos de correo electrónico, indicaciones, respuestas del proveedor ni credenciales.

Unidades instaladas

Entorno	Servicio	Temporizador	Archivo de estado
Desarrollo	`riveroaks-workflow-health-dev.service`	`riveroaks-workflow-health-dev.timer`	`/var/lib/riveroaks-workflow-health/development.json`
Producción	`riveroaks-workflow-health-production.service`	`riveroaks-workflow-health-production.timer`	`/var/lib/riveroaks-workflow-health/production.json`

El servicio y el temporizador profundos solo de producción son riveroaks-sermon-readiness-production.service y riveroaks-sermon-readiness-production.timer.

Los archivos de estado contienen solo claves de incidente hasheadas y metadatos operativos limitados. Solo son escribibles por la cuenta de trabajador del portal. Instale desde la raíz del portal desplegada correspondiente:

sudo scripts/install-workflow-health-watch.sh development
sudo scripts/install-workflow-health-watch.sh production

No instale la unidad de producción desde una extracción de desarrollo. Producción debe usar código ya fusionado y desplegado en la raíz de producción.

Verificaciones de rutina

Verifique el temporizador de producción y la ejecución más reciente sin leer los archivos de entorno:

systemctl status riveroaks-workflow-health-production.timer --no-pager
journalctl -u riveroaks-workflow-health-production.service -n 30 --no-pager

Ejecute la verificación --status segura para el contenido a través de una unidad transitoria de systemd para que reciba el mismo archivo de entorno protegido y la configuración de unidad no secreta que el monitor. Invocar el archivo de Python directamente no carga la configuración de la unidad e informará correctamente environment_invalid.

sudo systemd-run --quiet --wait --pipe --collect \
  --unit=riveroaks-workflow-health-production-status \
  --uid=www-data \
  --property=EnvironmentFile=/etc/riveroaks-portal/production.env \
  --setenv=WORKFLOW_ALERT_ENVIRONMENT=production \
  --setenv=WORKFLOW_ALERT_PORTAL_BASE_URL=https://portal.ro.church \
  --setenv=WORKFLOW_ALERT_TRANSCRIPTS_ENABLED=1 \
  --setenv=WORKFLOW_ALERT_TRANSCRIPT_TIMER_UNIT=riveroaks-service-transcripts-production.timer \
  --setenv=WORKFLOW_ALERT_TRANSCRIPT_SERVICE_UNIT=riveroaks-service-transcripts-production.service \
  /opt/riveroaks-service-transcripts/bin/python \
  /usr/share/nginx/portal/scripts/workflow-health-watch.py --status

Una ejecución de monitor saludable sale con éxito incluso cuando encuentra un incidente de flujo de trabajo; el estado de alerta y el correo electrónico comunican la falla del flujo de trabajo. El contrato --status --json sin contenido sale con un valor distinto de cero cuando el monitor está obsoleto o una dependencia sistémica de sermones no está disponible. Una carga fallida no marca falsamente todo el servicio como fuera de línea.

El portal expone el mismo contrato limitado en /health/sermon-slides.php. Devuelve solo el servicio, el entorno, el estado agregado y la antigüedad del monitor. Nunca devuelve detalles del incidente, rutas, nombres de host, metadatos de sermones, contenido, direcciones de correo electrónico o configuración. Uptime Kuma debería usar un monitor de palabras clave HTTP, requerir la cadena literal "service":"sermon-slides", verificar la URL de producción cada 60 segundos con dos reintentos, usar un tiempo de espera de 15 segundos y aceptar solo 200 a 299. HTTP 503 significa que el monitor está obsoleto o una dependencia sistémica no está disponible. Una advertencia de capacidad devuelve HTTP 200 con status=degraded; el correo electrónico enfocado contiene la métrica segura y la remediación.

El monitor instalado se llama Preparación de Diapositivas de Sermones. Utiliza la ruta de notificación NTFY existente. Mantenga esa ruta independiente de MailerSend; de lo contrario, una interrupción del proveedor de correo electrónico podría silenciar ambas capas.

Retención y recuperación de capacidad del portal

El sistema de archivos raíz de la VM del portal es parte de la preparación de diapositivas de sermones. Se genera una advertencia al 85% de uso o menos de 5 GiB libres; se genera una condición crítica al 95% de uso o menos de 1 GiB libre. No baje estos umbrales para resolver un incidente.

Los archivos stdout y stderr de Node-RED de PM2 locales son registros operativos, no un archivo de sermones autoritativo. Se gestionan desde riveroaks/infra mediante deploy/targets/portal/rocc-db-log-retention.json. El temporizador instalado verifica los archivos cada 15 minutos, rota cada uno a 50 MiB, comprime los archivos y retiene siete rotaciones. Utiliza copytruncate, por lo que la rotación no reinicia Node-RED. Los originales de Google Drive, las cargas de sermones protegidas, el historial de procesamiento de SQL, las bases de datos y el montaje multitrack de solo lectura están fuera de esta política.

Las verificaciones de rutina no contienen contenido:

systemctl status riveroaks-pm2-logrotate.timer --no-pager
systemctl show riveroaks-pm2-logrotate.service --property=Result --value
sudo du -x -m --max-depth=1 /home/riveroaks/.pm2 | sort -n
df -h /

Si los registros de PM2 heredados sin límites ya consumieron el sistema de archivos, primero demuestre los enlaces activos exactos sin mostrar el contenido del registro:

PM2_HOME=/home/riveroaks/.pm2 \
  /home/riveroaks/.nvm/versions/node/v18.18.2/bin/node \
  /home/riveroaks/.nvm/versions/node/v18.18.2/lib/node_modules/pm2/bin/pm2 jlist \
  | jq -r '.[] | [.name, .pm2_env.status, .pm2_env.pm_out_log_path, .pm2_env.pm_err_log_path] | @tsv'
sudo find /home/riveroaks/.pm2/logs -maxdepth 1 -type f \
  -name 'node-red-*.log' -printf '%f\t%u:%g\t%s bytes\n'

Solo después de que el proceso esté en línea y las dos rutas coincidan con los metadatos activos de PM2, un operador puede truncar esos archivos exactos en su lugar. El truncamiento mantiene válidos los descriptores de archivo abiertos y evita un reinicio de Node-RED, pero el historial de registro eliminado no se puede recuperar a través de la aplicación. No archive un registro de error de gran tamaño solo para conservarlo: los registros heredados pueden contener credenciales de proveedor o cargas útiles de mensajes. Capture solo categorías de error limitadas y marcas de tiempo, nunca contenido ni secretos. Cualquier credencial encontrada en un registro debe tratarse como comprometida, rotarse en el proveedor, reemplazarse a través del límite de tiempo de ejecución protegido y demostrarse rechazada después del cambio.

Después de que la capacidad se restablezca, implemente o verifique el temporizador administrado, luego ejecute el monitor de flujo de trabajo de producción una vez. Confirme que /health/sermon-slides.php devuelve HTTP 200 sin storage_warning, y confirme que el correo electrónico de recuperación desduplicado llega al destinatario de alerta de flujo de trabajo configurado actualmente. No elimine el archivo de estado del monitor para forzar la recuperación; el estado del incidente anterior es lo que causa el mensaje de recuperación legítimo.

Utilice tres fuentes separadas durante el triaje:

Uptime Kuma responde si el bucle de monitoreo y el servicio de sermones sistémico están actualmente disponibles.
El correo electrónico enfocado identifica la dependencia limitada y la próxima acción segura.
Los eventos de procesamiento SQL y el registro de systemd proporcionan historial a nivel de ejecución y IDs de correlación.

Triaje de alertas

Confirme el entorno en el asunto antes de cambiar nada.
Abra el enlace de ejecución segura en la alerta. Para diapositivas, inspeccione la línea de tiempo de procesamiento del portal más reciente y su primera etapa fallida. Para transcripciones, inspeccione el estado de la cola y el registro del trabajador de transcripción de systemd.
Si la alerta identifica un trabajador, restaure primero el servicio de systemd nombrado. Verifique si un reintento posterior ya se completó. El monitor borra una etapa fallida cuando existe un evento exitoso posterior para esa carga y etapa, cuando una ejecución más nueva para la carga alcanza ready o stored, o cuando todas las notificaciones pertenecientes a la ejecución afectada han alcanzado posteriormente sent. Esto preserva el evento fallido como historial de auditoría sin mantener una carga recuperada en estado de interrupción.
Repare la dependencia o utilice la ruta normal de reimplementación/reintento del portal. No pida a un pastor que vuelva a cargar para una interrupción de Mac, temporizador, lista de reproducción, Drive o proveedor.
Deje intacto el archivo de estado del incidente. Las dos verificaciones siguientes verifican la condición resuelta y el monitor envía el mensaje de recuperación automáticamente.

Para propresenter_playlist_api_timeout, inspeccione la API de ProPresenter de gráficos de transmisión y la versión de aplicación configurada. Para propresenter_playlist_store_timeout, mantenga ProPresenter cerrado, ejecute la preparación profunda, luego reimplemente la carga existente. Una reimplementación exitosa envía un informe de producción PROCESAMIENTO FIJO; los pasos posteriores de adoración y Drive que no se alcanzaron ya no se describen como fallas de computadora independientes.

Antes de trabajos planificados que se espera que interrumpan un receptor, habilite una ventana de mantenimiento limitada. Esto suprime nuevos correos electrónicos de interrupción e informa el servicio público como degradado, pero no detiene las verificaciones ni borra los incidentes. La ventana debe tener entre 15 minutos y 24 horas y expira automáticamente:

sudo systemd-run --quiet --wait --pipe --collect \
  --unit=riveroaks-workflow-health-production-maintenance \
  --uid=www-data \
  --property=EnvironmentFile=/etc/riveroaks-portal/production.env \
  --setenv=WORKFLOW_ALERT_ENVIRONMENT=production \
  --setenv=WORKFLOW_ALERT_PORTAL_BASE_URL=https://portal.ro.church \
  /opt/riveroaks-service-transcripts/bin/python \
  /usr/share/nginx/portal/scripts/workflow-health-watch.py \
  --maintenance-minutes 60 --maintenance-reason planned_receiver_work

Bórrela temprano con el mismo límite de unidad transitoria y --clear-maintenance. No edite el JSON de mantenimiento manualmente.

Si el monitor informa una falla de base de datos o esquema, valide las migraciones desplegadas y los permisos del archivo de entorno protegido antes de investigar filas de flujo de trabajo individuales. Si una Mac de transcripción no está disponible, el procesamiento puede continuar en la otra Mac, pero el host degradado aún necesita atención. Si todo el grupo de Mac no está disponible, ningún trabajo de transcripción local puede ejecutarse.

Una ranura de lista de reproducción de ProPresenter administrada cambiada o inválida es una falla de seguridad, no una interrupción transitoria. Restaure o reasigne la ranura antes de usar Redeploy; el trabajador intencionalmente no sigue reescribiendo una ranura inesperada. El mapeo de temas y las alertas de entrega diferida también requieren una acción administrativa y permanecen activas hasta que una ejecución más reciente resuelva la condición.

Para propresenter_playlist_persistence_timeout, deje ProPresenter disponible, confirme que su almacenamiento de lista de reproducción es escribible y reimplemente a través del portal. No cierre ni termine ProPresenter inmediatamente después de una actualización de la API. La colocación exitosa requiere tanto una lectura de la API como un cambio observado en el almacenamiento de la lista de reproducción en disco antes de que se cierre un proceso propiedad de la automatización.

Aceptación de producción del 12 de agosto de 2026

El despliegue en vivo completó las siguientes verificaciones:

el punto final de preparación sin contenido de desarrollo devolvió HTTP 200;
una alerta de desarrollo controlada fue aceptada por MailerSend con HTTP 202 y llegó a Gmail;
el monitor 15 de Uptime Kuma se configuró con el intervalo documentado, reintentos, palabra clave, tiempo de espera, rango HTTP y ruta NTFY;
una reimplementación normal del portal completó la generación de tercio inferior, ambas entregas de Mac, verificación de renderizado, publicación de vista previa de Drive y notificaciones de usuario/administrador;
el canary profundo detectó la actualización no persistente de la lista de reproducción en lugar de informar un estado listo falso;
la reparación con dirección UUID sobrevivió a un cierre/reapertura completo de ProPresenter;
los mensajes de alerta y recuperación de producción fueron aceptados por MailerSend;
el incidente de lista de reproducción profunda se recuperó sin editar el estado del monitor.

El mismo despliegue generó una storage_warning real: el sistema de archivos raíz del portal estaba aproximadamente al 90% de utilización con aproximadamente 6.7 GiB disponibles. Este es un comportamiento preventivo esperado. Reduzca la utilización o extienda el volumen; no debilite el umbral solo para que el estado de preparación sea verde.

Pruebas controladas

Previsualice una alerta sintética de desarrollo sin enviar correos electrónicos ni cambiar el estado en vivo. Utilice systemd-run también para los comandos controlados; nunca obtenga o imprima el archivo de entorno en un shell de operador.

sudo systemd-run --quiet --wait --pipe --collect \
  --unit=riveroaks-workflow-health-dev-dry-run \
  --uid=www-data \
  --property=EnvironmentFile=/etc/riveroaks-portal/dev.env \
  --setenv=WORKFLOW_ALERT_ENVIRONMENT=development \
  --setenv=WORKFLOW_ALERT_PORTAL_BASE_URL=https://dev.portal.ro.church \
  --setenv=WORKFLOW_ALERT_TRANSCRIPTS_ENABLED=0 \
  --setenv=WORKFLOW_ALERT_TRANSCRIPT_TIMER_UNIT=riveroaks-service-transcripts-dev.timer \
  --setenv=WORKFLOW_ALERT_TRANSCRIPT_SERVICE_UNIT=riveroaks-service-transcripts-dev.service \
  /opt/riveroaks-service-transcripts/bin/python \
  /usr/share/nginx/html/dev-portal/scripts/workflow-health-watch.py \
  --dry-run --scenario sermon-failure

Los escenarios compatibles son healthy, recovery, sermon-failure, transcript-failure, timer-stale y mac-pool-down. Una prueba de correo electrónico controlada debe nombrar explícitamente a su destinatario y nunca cambia el estado del monitor en vivo:

sudo systemd-run --quiet --wait --pipe --collect \
  --unit=riveroaks-workflow-health-dev-test-send \
  --uid=www-data \
  --property=EnvironmentFile=/etc/riveroaks-portal/dev.env \
  --setenv=WORKFLOW_ALERT_ENVIRONMENT=development \
  --setenv=WORKFLOW_ALERT_PORTAL_BASE_URL=https://dev.portal.ro.church \
  --setenv=WORKFLOW_ALERT_TRANSCRIPTS_ENABLED=0 \
  --setenv=WORKFLOW_ALERT_TRANSCRIPT_TIMER_UNIT=riveroaks-service-transcripts-dev.timer \
  --setenv=WORKFLOW_ALERT_TRANSCRIPT_SERVICE_UNIT=riveroaks-service-transcripts-dev.service \
  /opt/riveroaks-service-transcripts/bin/python \
  /usr/share/nginx/html/dev-portal/scripts/workflow-health-watch.py \
  --scenario transcript-failure --test-send cgood@riveroaks.org

sudo systemd-run --quiet --wait --pipe --collect \
  --unit=riveroaks-workflow-health-dev-recovery-test-send \
  --uid=www-data \
  --property=EnvironmentFile=/etc/riveroaks-portal/dev.env \
  --setenv=WORKFLOW_ALERT_ENVIRONMENT=development \
  --setenv=WORKFLOW_ALERT_PORTAL_BASE_URL=https://dev.portal.ro.church \
  --setenv=WORKFLOW_ALERT_TRANSCRIPTS_ENABLED=0 \
  --setenv=WORKFLOW_ALERT_TRANSCRIPT_TIMER_UNIT=riveroaks-service-transcripts-dev.timer \
  --setenv=WORKFLOW_ALERT_TRANSCRIPT_SERVICE_UNIT=riveroaks-service-transcripts-dev.service \
  /opt/riveroaks-service-transcripts/bin/python \
  /usr/share/nginx/html/dev-portal/scripts/workflow-health-watch.py \
  --scenario recovery --test-send cgood@riveroaks.org

Los mensajes de prueba están prefijados con CONTROLLED TEST. Ejecútelos en desarrollo a menos que se haya aprobado una prueba específica de producción. Una prueba de incidente real debe usar un fixture aislado y no debe alterar el contenido del sermón, el texto de la transcripción, la propiedad de la cola en vivo, los temporizadores, la autorización de Mac ni los artefactos de entrega.