Pitch: Nunca descubra que seu sistema caiu pelo cliente. Foi por isso que criei o Sentryn.
Durante anos trabalhando com sistemas utilizados diariamente por milhares de empresas, percebi um padrão que sempre me incomodou.
Quase todos os incidentes importantes começavam da mesma forma:
"Tem cliente dizendo que o sistema não está funcionando."
Essa frase sempre chegava tarde.
Quando o cliente é quem avisa primeiro, significa que alguém já perdeu tempo, deixou de trabalhar ou ficou frustrado tentando usar um sistema que deveria estar disponível.
Foi aí que comecei a me perguntar:
Por que a empresa não descobre isso antes?
Existem excelentes ferramentas de monitoramento no mercado. Eu mesmo já utilizei várias delas.
Mas, na prática, percebi que muitas equipes ainda resumem monitoramento a verificar se um site responde HTTP 200.
Para mim, saúde operacional sempre foi muito mais do que isso.
Uma operação depende de diversos componentes trabalhando em conjunto:
- Sites
- APIs
- Certificados SSL
- Domínios
- Disponibilidade
- Desempenho
- Incidentes
- Comunicação com clientes
Foi dessa ideia que nasceu o Sentryn.
Meu objetivo nunca foi criar "mais um uptime monitor".
Quero construir uma plataforma que ajude equipes a responder uma pergunta muito mais importante:
Como está a saúde operacional da minha empresa neste momento?
Depois de algumas semanas de desenvolvimento consegui colocar no ar o primeiro MVP.
Hoje a plataforma já possui:
- Monitoramento de sites
- Monitoramento de APIs
- Monitoramento de certificados SSL
- Monitoramento de domínios
- Gestão de incidentes
- Página pública de status
- Alertas
- Histórico de disponibilidade
Ainda existe muita coisa que quero desenvolver.
Mas decidi seguir uma filosofia que sempre admirei:
Lançar cedo. Aprender rápido. Evoluir com feedback de usuários reais.
Curiosamente, a programação acabou sendo a parte mais simples.
O que realmente consumiu tempo foi entender como explicar o valor do produto.
Definir posicionamento.
Escrever uma landing page.
Encontrar uma mensagem que qualquer pessoa entendesse em poucos segundos.
Escolher o que realmente deveria entrar no MVP.
Tudo isso foi muito mais difícil do que implementar funcionalidades.
Agora começa a etapa que considero mais importante.
Ouvir quem realmente trabalha com tecnologia.
Se você atua com infraestrutura, DevOps, SRE, desenvolvimento ou simplesmente já passou pela situação de descobrir um problema porque um cliente avisou primeiro, gostaria muito de ouvir sua opinião.
Meu objetivo neste momento não é vender.
É aprender.
Toda crítica, sugestão ou feedback será muito bem-vindo.
Obrigado!