🚨Uber larga o PagerDuty depois de 12 anos e acende um alerta
O Uber usou o PagerDuty por mais de 12 anos. Para quem não conhece, o PagerDuty é o serviço que acorda engenheiros de madrugada quando um sistema cai. É a sirene de incêndio da infraestrutura de tecnologia. Pois bem: o Uber decidiu abandoná-lo, e segundo Gergely Orosz, jornalista de tecnologia e ex-engenheiro do Uber, toda empresa de tech que ele conhece está fazendo o mesmo. --- A crítica é direta: o PagerDuty abriu capital na bolsa e, depois disso, 'dormiu no volante'. Não se adaptou quando o Slack mudou a forma como equipes se comunicam durante crises e, mais recentemente, não acompanhou a onda de automação com IA. O resultado é um produto que parou no tempo enquanto o mundo ao redor acelerou. --- É um lembrete importante para qualquer empresa de software: abrir capital e relaxar é receita para irrelevância. Seus clientes mais fiéis são, paradoxalmente, os que mais dói perder, porque quando eles saem, é sinal de que todo mundo já saiu ou está saindo.
O Uber usou o PagerDuty por mais de 12 anos. Para quem não conhece, o PagerDuty é o serviço que acorda engenheiros de madrugada quando um sistema cai. É a sirene de incêndio da infraestrutura de tecnologia. Pois bem: o Uber decidiu abandoná-lo, e segundo Gergely Orosz, jornalista de tecnologia e ex-engenheiro do Uber, toda empresa de tech que ele conhece está fazendo o mesmo.
— @GergelyOrosz View on X
O Uber encerrou sua parceria com o PagerDuty após mais de 12 anos. A migração, confirmada pelo jornalista e ex-engenheiro da empresa Gergely Orosz, reflete uma tendência mais ampla no mercado de tecnologia: grandes corporações estão trocando ferramentas legadas de gestão de incidentes por plataformas mais modernas, integradas e com capacidades de automação. Para equipes de engenharia no Brasil, a mudança sinaliza que o modelo tradicional de on-call e alertas manuais está em transição.
De padrão de mercado a legado
Durante anos, o PagerDuty foi a referência em operações de Site Reliability Engineering (SRE) e DevOps. No entanto, segundo Orosz, a empresa "dormiu no volante" após abrir capital. O produto não acompanhou a centralização da comunicação em ferramentas como o Slack durante crises, nem incorporou de forma efetiva a automação com inteligência artificial para triagem e resolução de incidentes. O resultado é uma solução que, para muitas equipes, hoje representa custo elevado sem a agilidade exigida por ambientes cloud-native.
O alerta para builders brasileiros
Para desenvolvedores e líderes técnicos no Brasil, a saída do Uber é um lembrete prático: a stack de observabilidade e incident response precisa evoluir junto com a arquitetura de software. Startups e fintechs locais já operam com infraestrutura distribuída, microserviços e práticas de platform engineering. Manter engenheiros presos a runbooks manuais e escalonamentos rígidos aumenta o toil e o risco de burnout. Ao avaliar alternativas, equipes devem observar: - Integração nativa com Slack, Microsoft Teams ou Discord para comunicação em tempo real durante incidentes; - Automação de runbooks e triagem com IA para reduzir o tempo médio de resolução (MTTR); - Escalonamento inteligente e analytics de post-mortem que alimentem a melhoria contínua; - Compatibilidade com stacks cloud-native e ferramentas de observabilidade já adotadas, como Datadog, Grafana ou Prometheus.
A armadilha da estagnação pós-IPO
A crítica de Orosz aponta para um padrão recorrente na indústria de software. Empresas que abrem capital e desaceleram a inovação do produto core tendem a perder exatamente os clientes mais difíceis de substituir: os enterprise. Quando uma companhia como o Uber migra, outras organizações interpretam o movimento como validação para revisar seus próprios contratos. A lição para builders é que relevância em tecnologia depende de ciclo contínuo de adaptação às novas formas de trabalho, e não apenas de estabilidade operacional.
O mercado de observabilidade e resposta a incidentes está se consolidando em plataformas que unem monitoramento, comunicação e automação. Para engenheiros e líderes técnicos no Brasil, a mensagem é direta: avaliar a stack de incident management agora evita uma migração complexa no futuro.