Cómo usar Upptime para crear tu propia página de estado gratis

18 jun 2026

Participación de IA

La IA ayudó a redactar, editar o revisar esta página.

Evalúa con cuidado los detalles importantes y confirma las decisiones críticas con fuentes primarias cuando sea necesario.

Cómo usar Upptime para crear tu propia página de estado gratis

Llevar toda la monitorización a un repositorio de GitHub: Actions como sondas, el repositorio como base de datos, Pages como CDN, Issues como registro de eventos. Cero servidores, cero cuotas mensuales, y de alguna manera se crea una página de estado funcional, consultable y con historial. Se puede llamar magia negra o sabiduría de los pobres, pero al final funciona.

Antecedentes

Al operar una pequeña matriz de productos con más de una docena de servicios externos, la pregunta “¿está funcionando o no?” se convirtió en una frase recurrente. Los clientes reportaban que no podían acceder, te conectabas por ssh y hacías curl y descubrías que funciona bien; unos minutos después vuelve a fallar, pero esta vez no lo viste. Las soluciones de monitorización comercial (Pingdom, el nivel premium de UptimeRobot, Datadog) por supuesto pueden resolver esto, pero cobran por sitio o por número de solicitudes, lo cual para un desarrollador independiente no es muy costeable ni en dinero ni en carga mental.

Lo más crítico es que la propia página de estado debe ser consultable por los usuarios. El escenario ideal: un dominio (por ejemplo status.hagicode.com) que muestre en tiempo real la disponibilidad de cada servicio, las curvas de tiempo de respuesta, el historial de incidentes, y que en caso de fallo pueda registrar y notificar automáticamente. El enfoque tradicional requiere reunir cuatro componentes: un servidor que ejecute cron, una base de datos para almacenar datos históricos, un sitio frontend, un CDN. Con estos cuatro componentes, el costo operativo supera rápidamente al de los servicios monitorizados, ya que es usar una espada de samurái para matar un mosquito, y el mosquito todavía se queja de falta de espacio.

Para resolver estos problemas, tomamos una decisión: trasladar todo el esquema de monitorización directamente a GitHub. Este cambio trajo beneficios mayores de lo que imaginabas—lo explicaré más adelante.

Sobre HagiCode

El esquema compartido en este artículo proviene de nuestra experiencia práctica en el proyecto HagiCode. HagiCode es un proyecto de asistente de código de IA, que expone más de una docena de servicios públicos incluyendo sitio web, documentación, endpoints de descarga, etc., impulsados por el repositorio principal HagiCode-org/site. Estos sitios deben ser estables y disponibles, por lo que la monitorización de estado para nosotros no es opcional, sino una necesidad. El esquema Upptime presentado a continuación es exactamente lo que HagiCode usa en su entorno de producción real—no lo inventé.

Análisis: Cómo funciona realmente Upptime

La esencia de Upptime es en realidad una plantilla de repositorio de GitHub, más seis workflows generados por la plantilla. La clave para entenderlo está en ver “quién llama a quién, cuándo, y qué resultado se produce y dónde se almacena”. Si lo desglosamos, deja de ser tan misterioso.

Flujo de datos: Un archivo de configuración lo controla todo

Todo el sistema gira alrededor de un único archivo de configuración declarativo .upptimerc.yml. La estructura de configuración real de HagiCode es aproximadamente así:

owner: HagiCode-org
repo: upptime

sites:
  - name: HagiCode Website
    url: https://www.hagicode.com
  - name: HagiCode Docs
    url: https://docs.hagicode.com
  - name: Server Package Index
    url: https://index.hagicode.com/server/index.json
  # ... un total de 14 sitios

status-website:
  cname: status.hagicode.com
  logoUrl: https://raw.githubusercontent.com/HagiCode-org/upptime/master/assets/upptime-icon.svg
  name: HagiCode Status
  introTitle: "**HagiCode Status**"
  introMessage: Real-time availability tracking for public HagiCode websites and download endpoints.
  navbar:
    - title: Status
      href: /
    - title: GitHub
      href: https://github.com/$OWNER/$REPO

Hay dos puntos que vale la pena mencionar. Primero, sites puede monitorizar tanto páginas web (que devuelven HTML) como endpoints JSON puros (como index.json); Upptime solo mira el código de estado HTTP y el tiempo de respuesta, no hace validación de contenido. Segundo, cname apunta a status.hagicode.com, lo que requiere que poseas ese dominio y configures el DNS para que apunte a GitHub Pages—después de todo, aunque sea gratis, el dominio es cosa tuya.

División de los seis workflows

Todos los archivos en .github/workflows/ tienen una advertencia en la parte superior: Do not edit this file directly!—son actualizados automáticamente cada semana por la plantilla, tú solo necesitas modificar .upptimerc.yml. Cada workflow se activa con cron, llama a diferentes subcomandos de la misma action upptime/uptime-monitor@v1.42.6, con responsabilidades bien definidas, lo cual es bastante conveniente:

Workflow	cron	Comando	Función
uptime.yml	*/5 * * * *	update	Verifica cada 5 minutos, escribe history/*.yml
response-time.yml	—	response-time	Calcula estadísticas de tiempo de respuesta
graphs.yml	—	graphs	Genera curvas PNG diario/semanal/mensual/anual
summary.yml	—	summary	Actualiza la tabla de estado en README
site.yml	0 1 * * *	site	Construye el sitio estático diario, despliega a Pages
update-template.yml	0 0 * * *	—	Sincroniza semanalmente con la plantilla upstream

El fragmento central de uptime.yml muestra cómo funciona la “sonda”:

on:
  schedule:
    - cron: "*/5 * * * *"
jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          token: ${{ secrets.GH_PAT || github.token }}
      - name: Check endpoint status
        uses: upptime/uptime-monitor@v1.42.6
        with:
          command: "update"
        env:
          GH_PAT: ${{ secrets.GH_PAT || github.token }}
          SECRETS_CONTEXT: ${{ toJson(secrets) }}

site.yml añade un paso más, usando peaceiris/actions-gh-pages@v4 para enviar los artefactos de compilación a la rama gh-pages:

- uses: peaceiris/actions-gh-pages@v4
  with:
    github_token: ${{ secrets.GH_PAT || github.token }}
    publish_dir: "site/status-page/__sapper__/export/"
    user_name: "Upptime Bot"
    user_email: "73812536+upptime-bot@users.noreply.github.com"

Persistencia de datos: Archivos como base de datos

Los resultados de monitorización no se guardan en una base de datos, sino que se hacen commit directamente en el repositorio como archivos. Esto puede sonar un poco salvaje, pero en la práctica funciona bien. Cada sitio tiene tres tipos de artefactos.

Instantáneas de estado history/{slug}.yml, por ejemplo history/hagi-code-website.yml:

url: https://www.hagicode.com
status: up
code: 200
responseTime: 96
lastUpdated: 2026-06-17T00:22:34.485Z
startTime: 2026-03-24T10:07:32.531Z

Fuentes de datos para badges de endpoint de shields.io api/{slug}/response-time.json, uptime.json:

{"schemaVersion":1,"label":"response time","message":"739 ms","color":"yellow"}

Y gráficos de tiempo de respuesta graphs/{slug}/response-time-{day,week,month,year}.png.

Este enfoque de “archivos como base de datos” está bien pensado: muchas escrituras y pocas lecturas, escala controlable (cada sitio acumula aproximadamente 288 muestras por día, se almacenan incrementos en lugar de datos completos), historial de versiones integrado, cero infraestructura. El precio es que el repositorio crecerá continuamente, de vez en cuando hay que revisarlo.

Eventos y notificaciones: Issues como registro de eventos

El registro de incidentes depende de GitHub Issues, junto con dos plantillas integradas en el repositorio: .github/ISSUE_TEMPLATE/bug_report.md (reporte de errores por usuarios) y maintainance-event.md (mantenimiento planificado). La plantilla de mantenimiento usa frontmatter para expresar la ventana de tiempo:

<!--
start: 2021-08-24T13:00:00.220Z
end: 2021-08-24T14:00:00.220Z
expectedDown: google, hacker-news
-->

Upptime analiza estos Issues y muestra “mantenimiento en curso” y “eventos pasados” en la página de estado y en README. Las notificaciones dependen del mecanismo de watch de Issue, más webhook, Slack, Telegram configurables (declarando notifications en la parte superior de .upptimerc.yml, el repositorio de ejemplo de HagiCode actualmente no lo tiene habilitado,毕竟能少一样是一样）。

Solución: Cinco pasos para replicar una página de estado

Replicar una página de estado idéntica a la de HagiCode, desde cero hasta en línea, son cinco pasos en total. Cinco pasos, pero cada uno no es largo, tómate tu tiempo.

Paso 1: Crear el repositorio desde la plantilla

No hagas git clone y luego modifica, usa directamente “Use this template” de GitHub para crear el repositorio (por ejemplo your-org/upptime). La plantilla ya incluye todos los workflows, plantillas de Issue y el esqueleto del sitio estático. Después de clonar a local, lo único que necesitas modificar manualmente es .upptimerc.yml—lo demás, déjalo como está.

Paso 2: Editar .upptimerc.yml

Cambia owner/repo a los tuyos, enumera las URLs a monitorear en sites, configura el sitio en status-website. La versión mínima funcional es aproximadamente así:

owner: your-org
repo: upptime

sites:
  - name: Main Site
    url: https://example.com
  - name: API Health
    url: https://api.example.com/health
    expectedStatusCodes:
      - 200

status-website:
  cname: status.example.com   # Si no tienes dominio, puedes borrar esto y usar el defecto your-org.github.io/upptime
  name: Example Status
  introTitle: "**Example Status**"
  introMessage: Monitorización de disponibilidad de servicios en tiempo real
  navbar:
    - title: Status
      href: /
    - title: GitHub
      href: https://github.com/$OWNER/$REPO

Opciones avanzadas: expectedStatusCodes limita los códigos de estado aceptables (por defecto 200-399); headers personaliza encabezados de solicitud (para endpoints que requieren autenticación); maxResponseTime marca respuestas lentas. Todo según necesites, usa lo que necesites.

Paso 3: Configurar Secret y permisos

Los workflows usan por defecto ${{ secrets.GH_PAT || github.token }}. github.token puede ejecutar el flujo básico, pero hay dos limitaciones que pueden causar problemas:

1. Los workflows activados por el token por defecto no activarán workflows downstream (para evitar bucles), lo que rompe la cadena “verificación → crear Issue → notificación”.
2. Permisos insuficientes para operaciones entre repositorios (por ejemplo, multi-organización).

Se recomienda crear un nuevo PAT (necesita permisos repo + workflow), guardarlo como Secret de repositorio GH_PAT. update-template.yml tiene una verificación especial: sin GH_PAT salta la actualización automática de plantilla e imprime un warning, por lo que este secret no es opcional, sino la clave para ahorrar dolores de cabeza.

Paso 4: Activar GitHub Pages

En Settings del repositorio → Pages → Source selecciona Deploy from a branch, rama gh-pages, directorio /root. site.yml cada día a la 1 AM enviará automáticamente los artefactos de compilación a esta rama. Si configuraste cname, añade un registro CNAME en tu proveedor de DNS apuntando a your-org.github.io.

También puedes activarlo manualmente por primera vez: en la página de Actions busca “Static Site CI” → Run workflow, no hace falta esperar la tarea programada,毕竟 ver resultados un segundo antes, el corazón está tranquilo un segundo antes.

Paso 5: Verificación y mantenimiento

Después de hacer push de la configuración, ve a Actions para ver si “Uptime CI” se ejecuta cada 5 minutos, si history/ comienza a aparecer archivos *.yml. La dirección de la página de estado es https://<your-org>.github.io/upptime/ o tu dominio personalizado. Para agregar sitios o cambiar dominio, solo necesitas modificar .upptimerc.yml, los workflows son totalmente automáticos. HagiCode ha mantenido la disponibilidad de 14 endpoints durante más de un año con este mecanismo, básicamente sin preocuparse.

Práctica: Ya hemos atravesado los obstáculos por ti

A continuación, algunas lecciones de la operación real de HagiCode, para que puedas evitar desvíos.

Práctica 1: Elección de granularidad de monitorización

HagiCode coloca páginas web (https://www.hagicode.com) y endpoints de datos puros (https://index.hagicode.com/server/index.json) en la misma lista sites. Para endpoints JSON, Upptime hace la solicitud y analiza el código de estado HTTP, pero no valida la estructura del contenido. Si necesitas una verificación profunda como “devuelve 200 pero el contenido es incorrecto”, puedes usar expectedStatusCodes y complementar con sondas externas; Upptime solo hace verificaciones HTTP de caja negra—solo mira el semblante, no lee el corazón.

Práctica 2: El uso ingenioso del badge de tiempo de respuesta

api/{slug}/response-time.json es la fuente de datos para badges de endpoint de shields.io. El README de HagiCode hace referencia extensiva a este tipo de URL:

https://img.shields.io/endpoint?url=https%3A%2F%2Fraw.githubusercontent.com%2FHagiCode-org%2Fupptime%2FHEAD%2Fapi%2Fhagi-code-website%2Fresponse-time.json

De esta manera, puedes incrustar badges de tiempo de respuesta en tiempo real en cualquier Markdown (README del proyecto, blog, páginas de terceros), el color se guía por el valor en message y el campo color. Nota: usa HEAD en lugar de master/main para hacer referencia a archivos raw, esto evita fallos masivos al cambiar el nombre de la rama—en los detalles, se esconde la estabilidad.

Práctica 3: Control del tamaño del repositorio

Con muestreo cada 5 minutos, al año history/ acumulará un volumen considerable. Upptime usa YAML incremental en lugar de registros completos, relativamente controlado, pero aún se recomienda revisar periódicamente el tamaño del repositorio. Si el valor de monitorización de cierto sitio disminuye, elimínalo de sites, también puedes limpiar manualmente los archivos históricos correspondientes—después de todo, si no lo quieres borrar, el repositorio tarde o temprano se hinchará para que lo veas.

Práctica 4: El uso real de eventos de mantenimiento

maintainance-event.md no es decorativo. Antes de un lanzamiento planificado, crea un Issue siguiendo la plantilla, llena start/end/expectedDown, Upptime marcará los sitios correspondientes durante este período como “mantenimiento planificado”, sin contar en las estadísticas de disponibilidad, evitando que un lanzamiento normal arrastre el SLA anual. expectedDown de HagiCode admite una lista de nombres de sitios separados por comas, correspondiente uno a uno con sites[].name.

Práctica 5: Límite entre actualizaciones de plantilla y personalizaciones

El Do not edit this file directly! en la parte superior de todos los .github/workflows/*.yml no es para asustar. update-template.yml cada semana sobrescribirá estos archivos con la plantilla upstream. Cuando necesites comportamientos personalizados, la forma correcta es usar opciones de configuración oficialmente soportadas en .upptimerc.yml (como skipTopics, customStatusWebsite, runnerSettings), en lugar de modificar workflows. Si realmente necesitas modificar workflows, o desactiva update-template.yml, o fork y mantén tu propia plantilla—esto último perderá actualizaciones sin dolor, weighs the pros and cons, tú lo valoras.

Práctica 6: Restricciones reales de cuotas gratuitas

GitHub Actions es gratuito para repositorios públicos, sin límite de tiempo, y el diseño de Upptime aprovecha precisamente esto. Los repositorios privados tienen 2000 minutos gratis al mes, mientras que uptime.yml se ejecuta cada 5 minutos y toma aproximadamente 1 minuto cada vez, solo este ítem consume aproximadamente 8640 minutos al mes, excediendo la cuota. Por lo tanto, el repositorio Upptime debe ser public, este es el requisito previo de “gratis”—no lo hagas private buscando privacidad y luego recibas la factura, eso sería incómodo.

Conclusión

Volviendo a la pregunta inicial: ¿hay alguna solución barata para monitorizar un montón de servicios externos? La respuesta de HagiCode es—sí, y es tan barata que te hará dudar si esto es real. Upptime descompone la monitorización en cuatro componentes nativos de GitHub:

• Sonda = cron de GitHub Actions
• Base de datos = archivos YAML/JSON en el repositorio
• CDN = GitHub Pages
• Registro de eventos = GitHub Issues

Obtienes: disponibilidad en tiempo real, curvas de tiempo de respuesta, eventos históricos, badges de disponibilidad, dominio personalizado, notificaciones automáticas, todo sin servidores, sin cuota mensual. El precio es mantener el repositorio público, y ocasionalmente preocuparte por el tamaño del repositorio. De hecho, este precio es mucho más ligero que construir un sistema de monitorización desde cero.

La razón por la que este esquema funciona es el subsidio sincero de GitHub al ecosistema de código abierto. Si también estás manteniendo una pequeña matriz de productos multi-sitio, te recomiendo encarecidamente dedicar una tarde a construirlo, mucho más fácil de usar que hacer monitorización manual.

Referencias

• Repositorio oficial de Upptime
• Documentación de badges de endpoint de shields.io
• Documentación de tareas programadas de GitHub Actions
• Ejemplo de página de estado de HagiCode

Resumen

En torno a “cómo usar Upptime para crear tu propia página de estado gratis”, una forma más sólida de avanzar es primero hacer funcionar gradualmente las configuraciones clave, los límites de dependencias y la ruta de implementación, luego completar los detalles de optimización.

Cuando los objetivos, pasos y puntos de verificación están claros, este tipo de esquemas generalmente pueden entrar en la entrega real de manera más fluida.

Traducción con IA

Esta página se tradujo desde la versión original en chino simplificado con ayuda de IA.

Consulta el original si necesitas verificar la redacción, los matices técnicos o las actualizaciones más recientes.

Ver original en chino simplificado

Tags:

• Upptime
• GitHub Actions
• Monitorización de estado
• Página de estado
• GitHub Pages
• HagiCode
• DevOps

Cómo publicar aplicaciones de Electron en Microsoft Store: desde el empaquetado MSIX hasta el envío a la tienda

Cómo Electron llama a las API nativas de Windows