Sitio público
- Se valida en build y deploy de `apps/site`.
- Sitemap y rutas públicas se generan estáticamente.
- Incidentes públicos se agregarán manualmente durante pilotos.
Status piloto
Transparencia operativa durante piloto
Esta página muestra cómo se revisa Fisnodo durante la fase piloto. Es manual, puede demorar en reflejar un incidente y no funciona como garantía legal de uptime ni como página de SLA.
Estado publicado
Última actualización manual de esta página: 2026-05-02. Automatizar el status externo queda para cuando haya usuarios productivos o partners dependiendo del servicio.
API
- El runbook usa `/health`, `/ready` y OpenAPI como smoke checks.
- La página no consulta esos endpoints en tiempo real.
- La automatización de uptime externo queda pendiente.
Consola
- El smoke de producción incluye acceso a `/app/login`.
- No se publican métricas de sesión o clientes.
- Problemas conocidos se documentarán aquí cuando afecten pilotos.
Workers y webhooks
- Los workers se revisan por servicio, métricas y colas.
- Webhook replay existe para recuperación operativa.
- Durante piloto, actualizaciones de incidentes son manuales.
Compromisos y límites
La confianza se construye diciendo qué existe y qué todavía no existe.
Lo que sí hay
- Runbook de deploy, smoke checks, restore e incidentes.
- Métricas protegidas para API, jobs, webhooks y certificados.
- Backups y manejo de credenciales documentados.
Límites actuales
- Sin porcentaje público de uptime.
- Sin SLA público general.
- Sin certificación SOC/ISO anunciada.
- Sin afiliación con DNIT.
Cuándo mejora
- Al iniciar pilotos externos.
- Cuando haya monitoreo externo automático.
- Cuando existan contactos de incidente por cliente o partner.
Cómo reportar
- Usar email o WhatsApp con RUC, endpoint, hora, documento y captura/error.
- Para webhooks, incluir delivery id si existe.
- Para documentos, incluir external_id o document_id.