--- title: "Fim de vida do Opsgenie: desligamento em 2027 e alternativas" description: "O Opsgenie será desligado em 5 de abril de 2027. Veja o que deixa de funcionar, o caminho de migração da Atlassian e uma alternativa leve para a entrega de alertas." date: 2026-07-11 author: Nooc authorAvatarLink: /images/avatars/nooc.webp authorLink: https://nooc.me tags: - Opsgenie - alternativa ao Opsgenie - alertas de plantão - gerenciamento de incidentes - migração --- # Fim de vida do Opsgenie: desligamento em 2027 e alternativas O Opsgenie será desligado em **5 de abril de 2027**. Depois dessa data, o produto deixa de ficar acessível, suas integrações e APIs REST param de funcionar e os dados de clientes que não tiverem sido migrados serão excluídos. Para a maioria dos times, o caminho oficial da Atlassian até o Jira Service Management é o substituto completo mais seguro. Mas, se você usa o Opsgenie principalmente para transformar eventos de monitoramento em alertas urgentes no celular, este também é um bom momento para decidir se ainda precisa de uma plataforma completa de gerenciamento de incidentes — ou apenas de uma camada de notificação menor. Este guia explica o prazo, o que muda e como escolher um caminho de migração sem deixar lacunas na cobertura de plantão. ## Datas do fim de vida do Opsgenie | Data | Mudança | | --- | --- | | 4 de março de 2025 | A Atlassian anunciou o fim da venda e do suporte do Opsgenie. | | 4 de junho de 2025 | As novas vendas do Opsgenie foram encerradas. Upgrades e downgrades de plano e novos sites deixaram de estar disponíveis. | | 5 de abril de 2027 | O Opsgenie é desligado e deixa de ficar acessível. Os dados de clientes não migrados são excluídos. | Os clientes atuais podem continuar usando o Opsgenie até a data do desligamento, mas esperar até as últimas semanas cria um risco evitável. A Atlassian recomenda concluir a mudança antes de 5 de abril de 2027. Consulte a [página oficial de migração do Opsgenie](https://www.atlassian.com/software/opsgenie/migration) e o [FAQ de licenciamento do Opsgenie](https://www.atlassian.com/licensing/opsgenie) para ver o cronograma atual. ## O que deixa de funcionar depois de 5 de abril de 2027? Quando o Opsgenie for desligado, os times perdem o acesso ao produto e a qualquer fluxo de trabalho que ainda dependa dele. Isso inclui: - Alertas e fluxos de plantão do Opsgenie - O aplicativo do Opsgenie para celular - As integrações do Opsgenie que ainda restarem - Os endpoints da API REST do Opsgenie - Dados e configurações que não foram migrados O corte afeta muito mais do que o painel web. Um monitor pode continuar detectando uma queda enquanto a antiga integração com o Opsgenie se transforma silenciosamente em um beco sem saída. O guia da Atlassian sobre [o que acontece quando o Opsgenie é desligado](https://support.atlassian.com/opsgenie/docs/what-happens-when-opsgenie-is-turned-off/) recomenda migrar primeiro todos os fluxos de alerta e de plantão. ## O substituto oficial: Jira Service Management O Jira Service Management é a escolha padrão quando você precisa preservar o modelo de operação mais amplo do Opsgenie: alertas, escalas, políticas de escalonamento, fluxos de incidentes e dados históricos. Os owners do Opsgenie podem abrir **Settings → Plan your move** para ver um plano recomendado do Jira Service Management e agendar a migração. Segundo a Atlassian, a maior parte dos dados e das configurações do Opsgenie pode ser sincronizada automaticamente depois que o plano de destino for selecionado e aprovado. Não presuma que todo recurso será transferido sem mudanças. A [comparação de recursos](https://support.atlassian.com/opsgenie/docs/feature-changes-and-deprecations-in-jira-service-management/) da Atlassian aponta métodos de contato que dependem do plano, recursos descontinuados, integrações que exigem configuração manual e endpoints de API que precisam ser atualizados. Uma limitação importante: a ferramenta de migração integrada ao produto oferece suporte a destinos no Atlassian Cloud, não ao Jira Service Management Data Center. Os times que permanecerem no Data Center precisam avaliar outro caminho em vez de contar com uma migração direta. A Atlassian documenta essa limitação no [guia de agendamento da migração](https://support.atlassian.com/opsgenie/docs/schedule-an-opsgenie-migration/). ## Quando faz sentido usar uma alternativa leve ao Opsgenie Nem toda conta do Opsgenie usa rodízios, árvores de escalonamento, linhas do tempo de incidentes e análises. Alguns times pequenos o usam para uma tarefa mais restrita: 1. Uma ferramenta de monitoramento detecta um evento crítico. 2. Uma integração encaminha o evento. 3. Um celular faz barulho suficiente para que alguém reaja. Se isso descreve a sua configuração, substituir a plataforma inteira pode adicionar mais processo do que você precisa. O Echobell é uma camada de entrega focada que aceita gatilhos por webhook ou e-mail e envia alertas normais, urgentes ou em formato de chamada no celular. O Echobell **não é um substituto um a um do Opsgenie**. Ele não substitui escalas de plantão avançadas, políticas de escalonamento, comando de incidentes nem relatórios pós-incidente. Para esses fluxos, use o Jira Service Management ou outra plataforma completa de gerenciamento de incidentes. O Echobell pode servir quando: - Sua fonte de monitoramento já decide quais eventos são críticos. - Um grupo pequeno e estável divide a responsabilidade do plantão. - Você quer a entrega direta do webhook para o celular sem refazer o monitoramento. - Você precisa de níveis de urgência diferentes para eventos críticos, de aviso e informativos. - Você quer testar a entrega de alertas de forma independente antes de mudar o resto da stack. Para uma decisão recurso a recurso, veja [Echobell vs Opsgenie](/pt/features/comparisons/opsgenie). ## Como testar o Echobell antes do desligamento do Opsgenie A migração mais segura é um teste em paralelo, não uma virada única no prazo final. ### 1. Escolha uma fonte de alertas crítica Comece por um serviço de produção com responsável claro e volume de alertas previsível. Evite migrar todas as integrações de uma vez. ### 2. Crie um canal no Echobell Crie um canal para o serviço e compartilhe-o com as pessoas que precisam receber o alerta. Cada inscrito pode escolher o comportamento de notificação adequado no próprio dispositivo. ### 3. Adicione um segundo destino de webhook Mantenha o caminho atual do Opsgenie ativo e adicione o webhook do canal do Echobell à fonte de monitoramento. Um payload básico de teste é assim: ```bash curl -X POST https://hook.echobell.one/t/ \ -H "Content-Type: application/json" \ -d '{ "title": "Production API is down", "body": "Health check failed in us-east-1", "severity": "critical", "externalLink": "https://status.example.com/incidents/123" }' ``` Use um token de exemplo em scripts e gerenciadores de segredos; não faça commit da URL real do webhook de um canal no controle de versão. A [documentação de webhook](/pt/docs/webhook) cobre as variáveis de payload e os modelos. Se a fonte oferece suporte a e-mail, mas não a webhooks, use um [gatilho por e-mail](/pt/docs/email-trigger). ### 4. Mapeie a urgência com critério Reserve os alertas em formato de chamada para eventos que exigem resposta imediata. Use alertas urgentes para avisos importantes e notificações normais para eventos informativos. Isso mantém o caminho urgente confiável, em vez de recriar a fadiga de alertas em um novo aplicativo. ### 5. Rode os dois caminhos durante um plantão real Compare o tempo de entrega, a clareza das mensagens, os falsos positivos e a reação de quem está de plantão. Teste também as notificações de recuperação — não só as falhas. ### 6. Documente o que o Echobell não substitui Antes de remover o Opsgenie desse serviço, defina um responsável para cada requisito remanescente de escala, escalonamento, confirmação, auditoria ou relatório. Se esses requisitos forem essenciais, mantenha-os em um sistema completo de gerenciamento de incidentes. ## Checklist de migração do Opsgenie Use este checklist antes do desligamento em 5 de abril de 2027: - Inventarie todas as integrações de entrada, heartbeats, clientes de API e integrações por e-mail. - Exporte ou migre os dados históricos que o seu time precisa manter. - Registre escalas, políticas de escalonamento, regras de notificação e responsáveis. - Identifique recursos e integrações descontinuados que precisam de substituição manual. - Atualize os scripts que chamam endpoints `opsgenie.com` ou `opsgenie.net`. - Teste alertas, recuperações, confirmações e entrega fora do horário comercial. - Rode o caminho antigo e o novo em paralelo por pelo menos um ciclo de plantão representativo. - Só remova o caminho antigo depois que o time de plantão confirmar que o substituto funciona. ## Perguntas frequentes ### O Opsgenie está sendo descontinuado? Sim. As novas vendas terminaram em 4 de junho de 2025 e o suporte ao Opsgenie se encerra em 5 de abril de 2027. Segundo a Atlassian, o produto será desligado nessa data e deixará de ficar acessível. ### O que vai substituir o Opsgenie? O caminho de substituição oficial da Atlassian é o Jira Service Management, onde os recursos de alerta e de plantão do Opsgenie estão sendo consolidados. A alternativa certa depende de o seu time precisar de gerenciamento completo de incidentes ou apenas de uma entrega confiável de alertas. ### O Echobell pode substituir totalmente o Opsgenie? Não. O Echobell substitui a camada de notificação urgente no celular em fluxos adequados. Ele não reproduz as escalas, as árvores de escalonamento, os processos de gerenciamento de incidentes nem os relatórios do Opsgenie. ### Dá para usar o Echobell durante uma migração do Opsgenie? Sim. Aponte uma fonte de alertas para os dois destinos, valide a entrega durante um ciclo de plantão real e mantenha o Opsgenie ativo até que o novo caminho esteja comprovado. ### Quando devemos começar a migrar? Comece agora o inventário e o teste piloto. A data final da migração depende da quantidade de integrações, dos requisitos de conformidade e de você estar indo para o Jira Service Management ou redesenhando a sua stack de alertas. ## Escolha o menor substituto que dê conta do trabalho real O desligamento do Opsgenie cria um prazo firme, mas isso não significa que todo time precisa do mesmo substituto. Escolha o Jira Service Management se você depende do Opsgenie como um sistema completo de plantão e gerenciamento de incidentes. Considere uma camada de entrega focada se os seus monitores já contêm a lógica de roteamento e a sua principal necessidade é levar um evento crítico rapidamente até os celulares certos. [Baixe o Echobell para iPhone](https://apps.apple.com/app/apple-store/id6743597198?pt=128151925&ct=blog-opsgenie-end-of-life-pt&mt=8) ou [obtenha na Google Play](https://play.google.com/store/apps/details?id=one.echobell.echobellandroid) e depois teste um alerta de produção enquanto a sua rota atual do Opsgenie ainda estiver ativa.