[{"data":1,"prerenderedAt":161},["ShallowReactive",2],{"seo-verification":3,"blog-self-hosted-opsgenie-alternatives-before-april-2027-en":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-self-hosted-opsgenie-alternatives-before-april-2027-en",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":27,"featuredImage":29,"bgImage":30,"posterImage":31,"relatedSolution":29,"intro":32,"sections":33,"ctaTitle":124,"ctaBody":125,"ctaButton":126,"ctaUrl":127,"relatedPosts":128},466,"self-hosted-opsgenie-alternatives-before-april-2027",{"fr":12,"en":10,"ar":13,"es":14},"opsgenie-eol-alternatives-self-hosted-incident-management","بدائل-self-hosted-لـ-opsgenie-قبل-ابريل-2027","alternativas-self-hosted-a-opsgenie-antes-de-abril-2027","Self-hosted Opsgenie alternatives before April 2027","Opsgenie shuts down on April 5, 2027. Learn how to migrate to OneUptime or IncidentRelay, two open source tools deployable on a VPS in under an hour.",8,0,false,"2026-10-18T00:00:00+00:00","2026-10-18T21:57:56+00:00",{"id":17,"name":23,"slug":24,"color":25,"icon":26},"Security & Monitoring","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[28],{"id":17,"name":23,"slug":24,"color":25,"icon":26},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fopsgenie-eol-alternatives-self-hosted-incident-management-poster.svg","On April 5, 2027, Opsgenie will permanently shut down. Atlassian published the official end-of-life announcement and is recommending users migrate to other products. Weeks earlier, Grafana Labs archived the Grafana OnCall OSS repository on March 24, 2026, removing one of the most frequently cited open source alternatives. These two events leave teams running their own infrastructure without an obvious path forward. This article covers two fully self-hosted alternatives — OneUptime and IncidentRelay — that can be deployed on a standard VPS, configured in under an hour, and maintained without a SaaS subscription. It complements the existing guides on lightweight monitoring with Beszel and Uptime Kuma, and on deploying Wazuh for intrusion detection.",[34,38,50,87,90,108,111,114,118,121],{"type":35,"title":36,"body":37},"h2","Opsgenie and Grafana OnCall: two pillars fading out","Opsgenie was acquired by Atlassian in 2018 and gradually absorbed into the Jira suite. The end-of-life announcement was published on the official Atlassian status page: the service stops on April 5, 2027. Users have just over a year to migrate their on-call policies, integrations and incident history. Grafana OnCall OSS, the open source component of Grafana OnCall, was archived on GitHub on March 24, 2026. The Grafana Labs team stated that the cloud version remains available, but the self-hosted repository no longer receives patches or new features. Teams that had built their incident management infrastructure on this component are in the same position: they must migrate before unpatched security vulnerabilities become a real risk. The convergence of these two events in less than twelve months creates a migration window that teams would do well to plan now rather than waiting for pressure to build in the final weeks before the April 2027 deadline.",{"type":39,"title":40,"items":41},"ul","What an incident management solution must cover",[42,43,44,45,46,47,48,49],"Receiving and deduplicating alerts from Prometheus, Grafana, Zabbix or any HTTP webhook","Routing alerts to the right teams based on configurable rules (severity, service, schedule)","Managing on-call schedules with weekly or custom rotations","Automatic escalations if an alert is not acknowledged within a defined time window","Multi-channel notifications: email, SMS, voice call, Slack, Microsoft Teams, PagerDuty webhooks","Public status page to keep users informed in real time","Searchable and exportable incident history for post-mortems","REST API for integration into CI\u002FCD pipelines and automation tools",{"type":51,"title":52,"rows":53,"headers":82},"comparison","OneUptime vs IncidentRelay vs PagerDuty",[54,59,63,68,73,78],[55,56,57,58],"License","Apache 2.0","MIT","Proprietary",[60,61,61,62],"Hosting","Self-hosted (Docker Compose)","Cloud only",[64,65,66,67],"Tech stack","Node.js \u002F TypeScript, PostgreSQL","Go, SQLite\u002FPostgreSQL","Undisclosed",[69,70,71,72],"Minimum recommended RAM","4 GB (light production), 8 GB advised","512 MB (SQLite), 2 GB (PostgreSQL)","N\u002FA",[74,75,76,77],"Built-in status page","Yes, public and customizable","Yes, basic","Yes, via Statuspage (paid separately)",[79,80,80,81],"Base price","Free (self-hosted)","From $21\u002Fuser\u002Fmonth",[83,84,85,86],"Criterion","OneUptime","IncidentRelay","PagerDuty (SaaS)",{"type":35,"title":88,"body":89},"VPS requirements for OneUptime","OneUptime uses a multi-container architecture orchestrated by Docker Compose. For a team of fewer than twenty people with moderate alert volume (fewer than one thousand events per day), a VPS with 4 vCPU and 8 GB of RAM is a solid baseline. Below 4 GB of RAM, several containers compete at startup and cause repeated restarts. Storage should be on an SSD volume: OneUptime writes frequently to PostgreSQL and its internal event bus. Plan for at least 40 GB for logs and the database over six months. The server must expose ports `80` and `443`; an nginx or Caddy reverse proxy can sit in front if the VPS already hosts other services. Docker Engine version 24 or later and Docker Compose version 2.20 or later are required. A fixed IP address and a domain name with a DNS A record are needed for the TLS certificate and so that incoming webhooks are reachable.",{"type":91,"title":92,"steps":93},"steps","Deploy OneUptime on a VPS in 7 steps",[94,96,98,100,102,104,106],{"body":95},"Connect to the VPS via SSH and install Docker Engine and Docker Compose v2 from the official Docker repository: `curl -fsSL https:\u002F\u002Fget.docker.com | sh`, then verify with `docker compose version`.",{"body":97},"Clone the OneUptime repository: `git clone https:\u002F\u002Fgithub.com\u002FOneUptime\u002Foneuptime.git` then enter the directory `cd oneuptime`.",{"body":99},"Copy the example configuration file: `cp .env.example .env` then open it in an editor. At a minimum set `DOMAIN` (your domain or subdomain), `DISABLE_TELEMETRY=true` if you do not want to send usage metrics, and the SMTP variables (`SMTP_HOST`, `SMTP_PORT`, `SMTP_USERNAME`, `SMTP_PASSWORD`, `SMTP_FROM_EMAIL`) for email notifications.",{"body":101},"Start the containers in the background: `docker compose up -d`. The first startup downloads images and runs database migrations; allow three to five minutes depending on bandwidth.",{"body":103},"Verify that all services are healthy: `docker compose ps`. The containers `oneuptime-app`, `oneuptime-worker`, `oneuptime-postgres` and `oneuptime-redis` should show state `running`. If a container errors, inspect its logs with `docker compose logs \u003Ccontainer-name> --tail=100`.",{"body":105},"Open a browser at `https:\u002F\u002Fyour-domain` and create the initial admin account. Then go to *Settings → On-Call Duty → Policies* to create your first policy: define the team, time windows and notification channels.",{"body":107},"Enable automatic image updates with Watchtower or schedule a weekly `docker compose pull && docker compose up -d` via cron to pull security patches without extended downtime.",{"type":35,"title":109,"body":110},"Configuring alerts: Prometheus webhook to OneUptime","OneUptime exposes an incoming webhook endpoint for each monitor or integration created. In the interface, go to *Integrations → Incoming Webhooks* and create a new integration of type Prometheus Alertmanager. The interface generates a URL in the form `https:\u002F\u002Fyour-domain\u002Fapi\u002Fv1\u002Fincoming-request\u002F\u003Cuuid>`. In the Prometheus Alertmanager configuration, add a receiver of type `webhook` pointing to this URL. The field `send_resolved: true` allows OneUptime to automatically close an incident when Alertmanager sends the resolution notification. For integration from Grafana, use the *Webhook* contact type and provide the same URL. OneUptime parses the incoming JSON and automatically extracts the title, severity and labels from the Prometheus alert. If you send alerts from a custom tool, the expected format is documented in the integration page: a `title` field and a `description` field are sufficient to create an incident.",{"type":35,"title":112,"body":113},"Managing on-call schedules and escalations","On-Call Schedules in OneUptime define who is available, at what time and for which service. A schedule is associated with one or more layers: each layer represents a team rotation. The rotation can be daily, weekly or over a custom period. Each team member can set their notification preferences in their profile: immediate email, SMS after two minutes, voice call if the incident is not acknowledged after five minutes. Escalations are configured in Alert Policies: if the on-call person at level 1 does not respond within the configured window, the alert automatically escalates to level 2, which can be a different person, a different team or a shared Slack channel. This escalation chain is visible in the history of each incident, which makes post-mortem reviews straightforward.",{"type":115,"title":116,"body":117},"tip","Exposing the status page behind nginx","OneUptime generates a public status page accessible at a dedicated subdomain, for example `status.your-domain.com`. To expose it cleanly behind nginx as a reverse proxy, create a vhost that forwards requests to the internal port `3105` used by the status page container: `proxy_pass http:\u002F\u002F127.0.0.1:3105;`. Enable the `X-Forwarded-Proto` header so that OneUptime generates correct HTTPS links in notifications. The TLS certificate can be obtained via Certbot with the nginx plugin: `certbot --nginx -d status.your-domain.com`. The status page lets customers and users follow service status in real time without accessing the admin interface.",{"type":35,"title":119,"body":120},"Troubleshooting — common startup errors","The most common issue at first startup is a PostgreSQL container that is not ready before the application container tries to connect. OneUptime includes `healthcheck` directives in its official `docker-compose.yml`; if you use a modified version, ensure the `app` service has a `depends_on` entry with condition `service_healthy` on the `postgres` service. A second frequent problem involves SMTP variables: if account verification emails are not sent, verify that `SMTP_PORT` is `587` (STARTTLS) and not `465` (direct SSL) if your SMTP provider requires it. To diagnose silent errors, watch the worker logs in real time with `docker compose logs -f oneuptime-worker`. Finally, if port `443` is already occupied by another service, OneUptime will start but be unreachable: change the port mapping in `docker-compose.yml` or stop the competing service before launching the stack.",{"type":35,"title":122,"body":123},"Planning the Opsgenie to OneUptime migration before April 2027","Opsgenie allows exporting alert policies, on-call schedules and incident history as JSON or CSV from *Settings → Export*. These exports contain routing rules, team members and active integrations. Import into OneUptime is not automatic: policies must be recreated manually or via the OneUptime REST API using the exported data. Starting with critical integrations (Prometheus, Grafana, Datadog) and then moving to on-call schedules and finally secondary notifications is the recommended approach. Plan for a parallel-run period of at least two weeks: both systems receive the same alerts while teams validate the new policies. The April 5, 2027 deadline leaves enough time for a careful migration if it is started before January 2027. Waiting until the final weeks risks a forced cutover with no option to roll back if an integration is missing.","Deploy OneUptime on a ServOrbit VPS","Deploy OneUptime in one click on a ServOrbit VPS — preconfigured template, data stays in your hands.","View the OneUptime template","\u002Fmarketplace\u002Fsecurite-monitoring\u002Foneuptime",[129,145],{"id":130,"slug":131,"slugs":132,"title":136,"excerpt":137,"readTime":138,"views":18,"isPinned":19,"publishedAt":139,"updatedAt":140,"category":141,"categories":142,"featuredImage":29,"bgImage":30,"posterImage":144,"relatedSolution":29},440,"proactive-vps-monitoring-beszel-uptime-kuma-v2",{"fr":133,"en":131,"ar":134,"es":135},"monitoring-alerte-proactif-self-hosted-vps","مراقبة-استباقية-vps-beszel-uptime-kuma","monitorizacion-proactiva-vps-beszel-uptime-kuma-v2","Proactive VPS monitoring: Beszel and Uptime Kuma v2","Deploy Beszel and Uptime Kuma v2 on a VPS to monitor your entire server fleet and receive Telegram or SMTP alerts before your clients notice the outage.",11,"2026-10-14T00:00:00+00:00","2026-10-14T23:33:30+00:00",{"id":17,"name":23,"slug":24,"color":25,"icon":26},[143],{"id":17,"name":23,"slug":24,"color":25,"icon":26},"\u002Fblog\u002Fcovers\u002Fmonitoring-alerte-proactif-self-hosted-vps-poster.svg",{"id":146,"slug":147,"slugs":148,"title":152,"excerpt":153,"readTime":154,"views":18,"isPinned":19,"publishedAt":155,"updatedAt":156,"category":157,"categories":158,"featuredImage":29,"bgImage":30,"posterImage":160,"relatedSolution":29},437,"self-host-wazuh-on-a-vps-full-soc-in-under-an-hour",{"fr":149,"en":147,"ar":150,"es":151},"self-host-wazuh-vps","استضافة-wazuh-على-vps-siem-مراقبة-أمنية-شاملة","self-host-wazuh-en-vps-soc-completo-en-menos-de-una-hora","Self-host Wazuh on a VPS: full SOC in under an hour","Deploy Wazuh 4.14 as a single node via Docker Compose on your VPS. Log management, incident detection and NIS2 art. 21 compliance under your control.",9,"2026-10-13T00:00:00+00:00","2026-10-13T14:10:28+00:00",{"id":17,"name":23,"slug":24,"color":25,"icon":26},[159],{"id":17,"name":23,"slug":24,"color":25,"icon":26},"\u002Fblog\u002Fcovers\u002Fself-host-wazuh-vps-poster.svg",1792361112199]