Página de detalle

• Vista completa de la configuración de cada servidor Nextcloud (PHP, OPcache, Redis, base de datos…) para servidores Extendidos/Push
• Página de detalle básica para servidores sin sonda: muestra versión, servidor web, protocolo HTTP y una sugerencia de actualización
• % de disponibilidad de 30 días y lista de incidentes recientes (inicio, fin, duración, motivo), calculados a partir del diario de transiciones de disponibilidad acotado — etiqueta honesta de "medido durante N días" mientras el diario sea más reciente que la ventana
• Reglas de advertencia de configuración con indicadores ⚠️, cada una reconocible (motivo + caducidad opcional)
• Sección de informe de auditoría del servidor cuando la instancia envía su informe mensual de nc-audit.sh
• Accesible haciendo clic en cualquier nombre de servidor o indicador de estado

Interfaz

• Panel centralizado con resumen de estado (las tarjetas de resumen muestran recuentos de sin conexión / certificado por caducar / aplicaciones a revisar solo cuando no son cero)
• Filtros avanzados por estado de Nextcloud, estado de PHP, estado general, imagen Docker en ejecución y búsqueda de texto
• Versiones oficiales obtenidas automáticamente de las fuentes de Nextcloud
• Calendario de lanzamientos con fechas de próximas versiones
• Interfaz FR / EN / DE (selector de idioma en la esquina superior derecha)

Administración

• Interfaz de administración para configurar reglas de versiones
• Tabla de resumen de modos de sonda en la parte superior: explica los tres métodos de recopilación (Básico, Extendido, Push) de un vistazo
• Gestión de servidores mediante interfaz web con diseño de tarjetas: dos zonas de sonda distintas (serverinfo / push), tokens enmascarados con opción de revelar, eliminación en línea
• Botón "Configurar sondas" por servidor para alternar zonas de tokens, estado guardado en localStorage
• Búsqueda de servidores en tiempo real con coincidencia insensible a acentos
• Generador de scripts Push: genera un script bash cron listo para usar (chmod 700) para la instancia remota de Nextcloud, actualizado automáticamente a medida que cambian las opciones
• Botón "Activar Push" en el panel: envía una solicitud push a todos los servidores push configurados (visible solo cuando existe al menos un servidor push, período de espera de 5 minutos)
• Configuración flexible de umbrales de seguridad por rama de Nextcloud

🏗️ Arquitectura```

ncstatuscheck/ ├── Frontend │ ├── index.php # Main entry point │ ├── template.html # HTML template (dashboard) │ ├── admin.html # Administration interface │ ├── detail.php # Server detail page │ ├── audit.php # Server-audit script distribution page (nc-audit.sh) │ ├── troubleshooting.php # Probe troubleshooting guide │ ├── app.js / admin.js / detail.js / audit.js / troubleshooting.js │ └── style*.css # One stylesheet per page family ├── APIs (HTTP) │ ├── api.php # Main monitoring API │ ├── detail-api.php # Detail page API (serverinfo + warnings + acks + availability) │ ├── push-api.php # Push reception + trigger + audit-report reception │ ├── ack-api.php # Warning acknowledge / unmute │ ├── admin-api.php # Version configuration routing │ ├── servers-admin-api.php # Server list management │ ├── nextcloud-versions-api.php # Official version scraping │ ├── nextcloud-apps-api.php # App store catalog (slim cache) for the apps audit │ ├── desktop-releases-api.php # Desktop client releases (GitHub, slim cache) │ ├── php-versions-api.php # PHP branch support data │ └── apps-warnings-api.php # Manual app warnings (known-bug list) CRUD ├── Shared modules (lib/) │ ├── auth.php # Auth + CSRF + URL redaction (defense in depth) │ ├── csrf-client.js # Auto-inject X-CSRF-Token in fetch() │ ├── nextcloud-client.php # Centralized HTTP client → remote Nextclouds │ ├── servers-store.php # Single source of truth for servers.json │ ├── uptime-state.php # Up/down state machine + transition journal + availability │ ├── alerts.php # Proactive alert dispatch: webhook + email digest │ ├── alerts-checks.php # Slow-signal alerts (SSL/version/push/audit/apps) + dedup state │ ├── smtp-mailer.php # SMTP transport adapter over vendored PHPMailer │ ├── phpmailer/ # Vendored PHPMailer (3 files + LICENSE, pinned in VERSION) │ ├── apps-warnings-manager.php # Manual app warnings storage │ ├── ui-common.js # NcUI: notify / confirm / prompt + shared app-audit messages │ ├── url-guard.php # Anti-SSRF (loopback, RFC1918, link-local…) │ ├── json-cache.php # Locked JSON read/write helpers │ └── version-config-manager.php # Version rules CRUD ├── Business logic │ ├── version-rules.php # NC / PHP status analysis engine │ ├── warnings-rules.php # Configuration warning engine │ ├── apps-rules.php # Installed-apps audit engine (store catalog cross-check) │ ├── cron-update.php # Full collection script, CLI only (twice a day) │ └── cron-ping.php # Lightweight up/down probe, CLI only (every 5 min) ├── Tools (never web-served — blocked by nginx/.htaccess) │ ├── tools/nc-audit.sh # Standalone server audit script (root, read-only) │ └── tools/ncstatuscheck-push-core.sh # Generic Push probe core (fleet-shared) ├── Tests │ └── tests/run.php # Plain-PHP test suite (no framework): php tests/run.php ├── Configuration │ ├── config.php # Central configuration (git-ignored) │ └── servers.json # Server list with tokens (git-ignored) └── Cache ├── servers_data.json # All server data ├── serverinfo_.json # Raw per-server cache (Extended) ├── push_.json # Last push payload per server ├── ack_.json # Acknowledged warnings per server ├── audit_.json # Last nc-audit.sh report per server ├── version-config.json # Version configuration ├── uptime_state.json # Up/down state per server (mini uptime) ├── uptime_history.json # Bounded up/down transition journal (availability % + incidents) ├── alerts_state.json # "Already alerted" memory of the check alerts ├── nextcloud_versions.json # Official NC versions ├── nextcloud_apps.json # App store slim catalog (apps audit) ├── apps-warnings.json # Manual app warnings (admin-curated) ├── .csrf_secret # CSRF HMAC secret (binary, 0600) └── *.log # Activity logs

deploy/ansible/ # Fleet deployment of the Push core (Ansible / scp) deploy/docker/ # Container packaging of the monitor itself

🚀 Instalación

Requisitos previos

• PHP 8.1+ con extensiones cURL y JSON — ese es el mínimo de sintaxis contra el que CI ejecuta las pruebas, no una recomendación de despliegue: tanto 8.1 como 8.2 ya han superado su fecha de fin de soporte de seguridad, usa una versión con soporte actual (8.3+ en el momento de escribir esto) para cualquier cosa expuesta a internet
• Servidor web nginx o Apache con HTTPS
• Acceso de red a los servidores Nextcloud que se van a monitorizar

Configuración del servidor web (nginx)```nginx

server { server_name monitoring.your-domain.com; root /var/www/ncstatuscheck; index index.php;

}

2. Configuración Crea tu archivo de configuración a partir de la plantilla:```bash cp config-example.php config.php

3. Añadir servidores

Los servidores se gestionan directamente desde la interfaz de administración (botón ⚙️ Admin). También puedes crear servers.json manualmente:```json [ {"url": "https://cloud.example.com"}, {"url": "https://nextcloud.mycompany.org", "serverinfo_token": "your_token_here"} ]

Si servers.json aún no existe (estás dejando que la interfaz de administración lo cree en lugar del paso manual anterior), el chmod 600 anterior simplemente no tiene nada sobre lo que actuar — eso está bien: ServersStore::save() aplica chmod al archivo a 0600 por sí mismo en cada escritura, por lo que un servers.json (re)creado a través de la interfaz de administración nunca permanece legible por grupo/mundo con tokens de serverinfo/push dentro.

5. Autenticación HTTP```bash htpasswd -c /etc/nginx/.htpasswd admin

Re-ejecutar esto añade duplicados si estas líneas ya están presentes — comprueba con crontab -l primero si no estás seguro.

cron-ping.php es intencionadamente mínimo: solo comprueba el status.php de cada instancia y actualiza el estado arriba/abajo (cache/uptime_state.json), por lo que puede ejecutarse con frecuencia sin carga. Una instancia solo se marca como caída después de UPTIME_FAIL_THRESHOLD sondeos fallidos consecutivos (por defecto 2 → ~10 min con una cadencia de 5 min); la recuperación a activa es inmediata. El cron-update.php completo permanece sin cambios para todo lo demás.

Docker (alternativa a instalación en bare-metal)

En lugar de los pasos 1–6 anteriores, NcStatusCheck también puede ejecutarse como un pequeño stack de docker compose (PHP-FPM + nginx + un contenedor cron) — el repositorio se monta por bind tal cual, sin paso de compilación ni Composer, por lo que refleja exactamente la estructura de bare-metal, solo que contenerizado. Sirve únicamente HTTP plano (puerto 8080 por defecto) — coloca tu propio proxy inverso con terminación TLS delante.

La configuración completa — configuración, los problemas de permisos (uid 82, pre-creación de servers.json), autenticación HTTP Basic, cron, actualizaciones y copias de seguridad — vive íntegramente en deploy/docker/README.md. Empieza ahí; esta sección es intencionadamente solo una referencia, para evitar mantener dos copias de los mismos pasos sincronizadas.

📋 Uso

Interfaz principal

• Ve a https://monitoring.your-domain.com
• Consulta el panel con el estado de todos tus servidores
• Usa los filtros para acotar por estado o búsqueda
• Comprueba las versiones oficiales y el calendario de lanzamientos

Administración

• Abre la interfaz de administración mediante el botón "⚙️ Admin"
• Una tabla resumen de modos de sondeo en la parte superior de la página explica las diferencias entre los métodos de recopilación Basic, Extended y Push
• Gestión de servidores: cada servidor se muestra como una tarjeta con dos zonas de sondeo plegables:
  • Zona Serverinfo: configura el token de lectura (NC → extracción de NcStatusCheck)
  • Zona Push: genera un token push y descarga el script cron listo para usar para la instancia remota
• Configuración de Nextcloud: establece versiones mínimas seguras por rama (efectos hover en las filas)
• Configuración de PHP: establece estados recomendados/soportados por versión

Página de detalle

Accesible haciendo clic en cualquier nombre de servidor o en su indicador de Health.

Para servidores Basic (sin sonda Extended ni Push), una página simplificada muestra los datos disponibles (versión de NC, servidor web, protocolo HTTP) con un aviso y una sugerencia para habilitar una sonda.

Para servidores Extended / Push, la página de detalle completa muestra secciones separadas:

API

NcStatusCheck expone varios endpoints REST:

API principal (api.php)

• GET ?action=get_data — Obtener datos (caché o actualización)
• POST ?action=refresh_data — Forzar la actualización de todos los servidores

API Push (push-api.php)

• POST con cabecera push_token — Recibir datos push de una instancia NC remota
• POST ?action=request_push_all — Solicitar un push inmediato de todos los servidores push configurados (establece un indicador de activación consumido por el script cron remoto)

El script cron generado por la interfaz de administración se divide en dos: un núcleo genérico /usr/local/bin/ncstatuscheck-push.sh — idéntico en cada servidor (toda la lógica) — controlado por una pequeña configuración por instancia /etc/ncstatuscheck/<slug>.conf (SERVER_URL, SLUG, OCC_CMD, DOCKER_ENABLED, SKOPEO_ENABLED). Se invoca como ncstatuscheck-push.sh /etc/ncstatuscheck/<slug>.conf [--test]. El núcleo se niega a cargar una configuración escribible por grupo/todos (anti inyección de código).

Es multi-destino (fan-out): los datos se recopilan una vez y se envían a cada monitor listado en /etc/ncstatuscheck/targets-<slug>.conf (una línea url|push_token[|http_user|http_pass] por monitor). El administrador de cada monitor emite un comando idempotente para registrarse.

Múltiples instancias de Nextcloud en un mismo host: las rutas por instancia se sufijan con un <slug> derivado de la URL monitorizada (p. ej. latest.ezeo.coop → latest_ezeo_coop): <slug>.conf, /etc/cron.d/ncstatuscheck-<slug>, targets-<slug>.conf, ncstatuscheck-push-<slug>.log, estado …-<slug>.<md5>.last. Solo el núcleo se comparte, por lo que las instancias co-ubicadas nunca colisionan.

Nextcloud ejecutándose en Docker (imagen oficial, compose, AIO): totalmente compatible — el script se instala en el host (cron root + acceso al daemon de Docker), nunca dentro del contenedor, y occ pasa por docker exec: OCC_CMD=docker exec -u www-data <container> php occ (contenedor AIO: nextcloud-aio-nextcloud). El generador de scripts de administración tiene un preajuste de tipo de instalación que rellena esto. Nunca añadas -t (sin TTY bajo cron); mantén -u www-data (la imagen oficial rechaza occ como root).

Despliegue/actualizaciones de flota: como el núcleo es un único archivo idéntico, actualizar la lógica en muchos servidores = reemplazar ese único archivo (el marcador ↑ señala servidores que ejecutan una versión anterior). Consulta deploy/ansible/ para un playbook listo para usar (o un simple bucle scp). El monitor permanece pasivo — nunca envía código a la flota; el ancla de confianza es tu propio acceso SSH, no el monitor.

Migración desde una instalación anterior a v4 (script monolítico por instancia): elimina el antiguo /usr/local/bin/ncstatuscheck-push-<slug>.sh y /etc/cron.d/ncstatuscheck-<slug> antes de instalar el núcleo + la configuración (el targets-<slug>.conf se reutiliza tal cual), de lo contrario harás doble push.

API de detalle (detail-api.php)

• GET ?server=<url> — Datos completos de serverinfo + advertencias calculadas para un servidor Extended/Push

APIs de administración

• admin-api.php — Configuración de versiones
• servers-admin-api.php — Gestión de servidores (get_servers, add_server, remove_server, update_server_token, generate_push_token, remove_push_token)
• nextcloud-versions-api.php — Versiones oficiales
• desktop-releases-api.php — Lanzamientos del cliente de escritorio de Nextcloud (get_desktop_releases, refresh_desktop_releases)

🩺 Auditoría de servidores (nc-audit.sh)

Un subsistema separado de la monitorización: un script bash independiente y de solo lectura (tools/nc-audit.sh) ejecutado como root en un servidor Nextcloud para una auditoría única / mensual del ajuste de web + PHP + base de datos, contrastada con la capacidad física de la máquina (RAM, CPU, tipo de disco). Orientado a una oferta de supervisión gestionada: el cliente lo instala, el monitor solo recibe informes — sin acceso a la máquina/red requerido. El script solo lee la configuración (sin cambios), imprime un informe en color y escribe una copia en /tmp.

Qué comprueba: capacidad del servidor (RAM/CPU/SSD-HDD, swappiness, detección de servidor compartido) · Nextcloud (versiones, cron, caché, Redis en tiempo de ejecución, tipo de BD, registros) · PHP/PHP-FPM (SAPI de servicio real, OPcache en tiempo de ejecución, memoria multi-pool) · Apache (memoria de trabajadores consciente de MPM) · Nginx · PostgreSQL · MariaDB · higiene de seguridad (fail2ban o CrowdSec + bouncer + blocklist comunitaria; actualizaciones pendientes / reinicio / servicios en librerías obsoletas) · conciliación del presupuesto de RAM (InnoDB + FPM + Apache frente a RAM real) · análisis profundo con herramientas opcionales si ya están presentes (mysqltuner, pt-variable-advisor, apache2buddy, sar/iostat).```bash

Download (the page distributes it; the repo raw URL is public)

curl -fsSL https://gitlab.com/jp.louvel/ncstatuscheck/-/raw/master/tools/nc-audit.sh -o /usr/local/bin/nc-audit.sh chmod 700 /usr/local/bin/nc-audit.sh

sudo nc-audit.sh # auto-detect, dedicated server sudo nc-audit.sh /var/www/nextcloud # explicit path (or NC_PATH=…) sudo NC_RAM_BUDGET_PCT=50 nc-audit.sh # shared host: size to 50% of RAM

El objetivo es un techo que el presupuesto permite, no un valor que debas fijar (solo aumenta un pool que realmente se satura). Los pesos son decisión tuya: la herramienta nunca los adivina.```bash

Weights you provide (a human judgment — the tool never guesses them):

sudo NC_RAM_BUDGET_PCT=70 NC_INSTANCES="poolA:4,poolB:2,poolC:1" nc-audit.sh

Interactive helper (terminal only): lists the pools, asks a weight for each,

prints the targets + a reusable NC_INSTANCES line:

sudo NC_RAM_BUDGET_PCT=70 nc-audit.sh --tune-fpm

Consulta config-example.php para ver la lista completa y comentada de opciones (incluyendo DEMO_MODE y PUSH_SCRIPT_VERSION).

🛡️ Seguridad

Medidas implementadas

• Autenticación HTTP Basic obligatoria, reforzada por una verificación de autenticación a nivel de aplicación en cada endpoint de administración (defensa en profundidad)
• Protección CSRF: token HMAC inyectado automáticamente en cada petición mutante (lib/csrf-client.js + csrf_require())
• Protección anti-SSRF en cada URL proporcionada por el operador (se rechazan loopback, RFC1918 y link-local; redirecciones solo HTTPS; verificación de IP tras la conexión)
• HTTPS obligatorio con certificados Let's Encrypt
• Protección de archivos de datos y registros: reglas de nginx (ver arriba) replicadas por los archivos .htaccess incluidos para Apache; servers.json con chmod 0600 automático (contiene tokens)
• Cabeceras de seguridad (CSP, X-Frame-Options, nosniff, Referrer-Policy) en cada página servida por PHP
• Validación estricta de URL en todas las entradas
• Scripts de cliente ejecutados como root: la configuración de la instancia se carga como root y el archivo de objetivos decide a dónde se envían los datos recopilados — ambos se rechazan a menos que no sean escribibles por grupo/otros ni pertenezcan a un tercero
• Aislamiento entre instancias monitorizadas: un push solo se acepta cuando la URL del cuerpo coincide con una entrada Y hash_equals() pasa con el token de esa entrada, por lo que un servidor monitorizado comprometido no puede leer ni sobrescribir los datos de otro. request_push / request_push_all están detrás de autenticación de administrador + CSRF. Verificado de extremo a extremo contra un escenario de cliente comprometido
• Informe de destinos de push: cada instancia declara a qué monitores envía sus pushes (solo URLs, nunca tokens); la página de detalle los muestra y se dispara una alerta cuando el conjunto cambia — una línea extra en targets.conf copiaría silenciosamente cada push a un tercero
• Saneamiento de la carga útil del push: los IDs de aplicación están en una lista blanca de caracteres; los campos Docker de formato libre (nombre, imagen, versión, estado) se limpian de <>"'& en la ingesta, además del escape en el momento del renderizado
• Verificación SSL/TLS para conexiones salientes — nunca deshabilitada, incluido el transporte de alertas SMTP
• Respuestas remotas limitadas (2 MB): un servidor monitorizado controla completamente lo que responde y nada autentica esa dirección. Sin límite, un servidor que solo transmita datos agotaría la memoria de PHP — un error fatal que ningún try/catch puede capturar, lo que mataría la ejecución de recopilación a mitad del bucle y, con ella, todas las alertas de toda la flota
• Anonimización en modo demo cubre más que la URL: nombres de contenedores, hosts de registries privados en referencias de imágenes y el hostname citado dentro de los mensajes de error de cURL se eliminan, tanto en el panel como en la página de detalle

Recomendaciones

• Usa contraseñas seguras para la autenticación HTTP
• Restringe el acceso a direcciones conocidas — la pestaña de filtrado de IP de administración genera las reglas por ti (ver abajo)
• Supervisa los registros en busca de intentos de intrusión
• Mantén PHP y las dependencias del sistema actualizados

Banner de salud de config.php (administración)

config.php está en gitignore y se edita a mano por servidor, por lo que se desvía — silenciosamente, ya que casi todas las constantes tienen un valor de respaldo en el código. Un banner en la parte superior de la página de administración informa de lo que realmente está mal, y solo cuando algo lo está: un PUSH_SCRIPT_VERSION dejado atrás por una actualización, ningún transporte de alertas configurado en absoluto, una etiqueta de cierre final que emite un byte antes de cualquier header(), un directorio de caché no escribible, constantes ausentes que caen silenciosamente en valores predeterminados.

Solo lectura por diseño y sin acción de guardado, por la misma razón que la pestaña de Notificaciones: config.php pertenece a root y contiene secretos. El contenido del archivo nunca viaja — solo hechos sobre él — y ningún secreto se lee.

Filtrado de IP (pestaña de administración)

Todo lo anterior es a nivel de aplicación: cualquiera en internet aún puede alcanzar el monitor y sondearlo, y solo la contraseña lo detiene. La pestaña de filtrado de IP genera las reglas que colocan una lista blanca delante de la aplicación, de modo que los hosts desconocidos no puedan hablar con ella en absoluto. Es defensa en profundidad, no un reemplazo de la autenticación Basic ni de los tokens de push — y solo produce texto para revisar y pegar, nunca escribe una configuración de servidor web o firewall.

Dos clases de origen, deliberadamente desiguales, para que un servidor monitorizado comprometido no pueda alcanzar la administración:

Las instancias sondeadas en modo Basic/Extended no abren ninguna conexión entrante y no reciben ninguna entrada de lista blanca.

Las direcciones provienen de dos fuentes, y la diferencia importa: el registro DNS de un dominio monitorizado es su dirección de ingreso, mientras que su push sale desde su egreso. Donde difieren, solo funciona la segunda. Por lo tanto, push-api.php registra la dirección de origen real de cada push (source_ip en la caché de push), y la pestaña la incluye en la lista blanca, informando de la discrepancia. Hasta que un servidor haya hecho push una vez, recurre a DNS A+AAAA y lo indica.

Tres salidas:

• nginx (recomendado) — un archivo conf.d autocontenido (geo + map) más una única línea if ($ncsc_forbidden) { return 403; } en el vhost. No es necesario duplicar el bloque fastcgi, los archivos estáticos también están cubiertos (admin.html es uno), y /.well-known/acme-challenge/ permanece abierto para que la renovación de certificados no se rompa silenciosamente.
• Apache 2.4 — <LocationMatch> con una búsqueda negativa hacia adelante más un <Location> para el endpoint de push, de modo que las dos secciones no puedan solaparse y nada dependa del orden de fusión de Apache. Todas las direcciones de una regla van en una línea Require ip: varias líneas dentro de <RequireAll> se combinan con AND, lo que nadie puede satisfacer.
• ufw — tosco por naturaleza (un filtro de paquetes ve puertos, no URLs), por lo que no puede expresar la división push/admin. Úsalo solo como capa exterior.

El generador se niega a emitir cualquier cosa cuando no se proporciona ninguna dirección de administración, advierte cuando la propia dirección del operador no está cubierta, y advierte cuando la petición llegó a través de un proxy (tanto geo como Require ip leen el peer de transporte, por lo que detrás de un proxy todos los clientes parecen iguales). El fragmento ufw generado coloca la regla SSH primero, mantiene el puerto 80 abierto para el desafío HTTP-01, y explica la trampa de IPv6: a diferencia de nginx, que rechaza una dirección v6 no listada, ufw no filtra v6 en absoluto a menos que IPV6=yes esté configurado — un host de doble pila estaría de otro modo completamente abierto a través de IPv6.

Límite conocido, señalado en la propia página: una vez aplicadas las reglas, esta pestaña no descubre nada nuevo. Un push rechazado es rechazado por el servidor web antes de llegar a PHP, por lo que la dirección registrada sigue siendo la última que logró pasar — y aún parece verificada. Dos consecuencias: añadir un servidor Push significa regenerar y reaplicar las reglas, o su primer push será rechazado; y si la dirección de una instancia cambia, la nueva solo se puede leer en el registro de acceso del servidor web (grep 'push-api.php' access.log | grep ' 403 '). Por lo tanto, la pestaña muestra la fecha de última aparición de cada dirección observada y la marca una vez que es más antigua que un ciclo completo de push perdido — el mismo umbral que la alerta push_stale, que cubre el mismo punto ciego desde el otro lado.

Distinguir un problema de filtrado de cualquier otro: un GET simple en el endpoint de push separa las capas limpiamente, sin efectos secundarios y sin necesidad de token — ejecútalo desde la máquina en cuestión, ya que lo que se juzga es la dirección saliente de esa máquina:```bash curl -sS -o /dev/null -w '%{http_code}\n' https://your-monitor/push-api.php

Sale con código de salida distinto de cero ante cualquier hallazgo crítico (fuga de código fuente, archivo secreto sin bloquear, almacén de tokens legible por cualquier usuario, autenticación Basic ausente), por lo que puede condicionar un despliegue: conéctalo a tu script de sincronización/despliegue como paso posterior. WARN/INFO nunca hacen fallar la ejecución.

🧪 Pruebas y desarrollo

Modo de desarrollo```php

// In config.php define('ENV', 'dev');

Cubre la lógica de negocio pura (reglas de versión/aplicaciones, advertencias, máquina de estados de tiempo de actividad y disponibilidad, máquina de estados de deduplicación/rearme de alertas, constructores de correos electrónicos).

🤝 Contribuciones

Reportar un error

Abre una nueva incidencia con:

• Una descripción detallada del problema
• Pasos para reproducirlo
• Registros de errores si están disponibles
• Tu configuración del entorno

Proponer una mejora

1. Abre una incidencia para discutir tu idea
2. Haz un fork del proyecto
3. Crea una rama para tu funcionalidad
4. Implementa con documentación
5. Envía una solicitud de fusión

📝 Licencia

Este proyecto está licenciado bajo GNU AGPL v3.

👥 Créditos

NcStatusCheck es desarrollado por ézéo, una cooperativa digital especializada en soluciones de código abierto.

Colaboradores

• Equipo de ézéo — Desarrollo inicial y mantenimiento

¿Necesitas ayuda? Consulta las incidencias o contacta con el equipo de ézéo.