Uma interface web por servidor
Cada servidor mostra apenas as próprias execuções. Verificar as falhas da noite passada em cinco servidores significa abrir cinco interfaces web.
Dagu Cloud
O plano de controle dos seus servidores Dagu
Conecte cada servidor Dagu self-hosted ao Dagu Cloud. Veja a saúde e as execuções de todos em um só console, alerte sua equipe onde ela trabalha, repita, pare e aprove execuções sem fazer login em cada servidor, e deixe o ChatGPT ou o Claude operá-los por um único endpoint MCP. Os workflows continuam rodando apenas nos seus servidores, que só fazem conexões de saída; nenhuma porta de entrada é aberta.
Grátis para um servidor. Team e Pro cobrem cada servidor licenciado e adicionam ações sobre execuções, MCP e sua equipe. O monitoramento requer Dagu v2.19.1 ou posterior (v2.19.2 no plano gratuito); ações sobre execuções e MCP requerem v2.22 ou posterior.
Seus servidores
- prod-eu-1dagu 2.19.0
- prod-us-2dagu 2.19.0
- batch-01dagu 2.19.0
Os workflows rodam aqui
HTTPS, apenas de saída, a cada 60 segundos
console.dagu.shNunca executa workflows
OverviewServersRunsAlertsNotifications
Alertas por e-mail, chat, PagerDuty ou webhook quando algo quebra, e de novo quando se recupera
Muitos servidores, nenhum lugar de onde operá-los
Cada servidor Dagu é completo por si só, com seu próprio agendador, histórico de execuções e interface web. Com vários servidores, isso também significa vários lugares para verificar, e vários lugares para fazer login quando uma execução precisa de intervenção.
Nenhuma lista com todas as falhas
Nada reúne as falhas de todos os servidores em um só lugar, então ninguém vê o quadro completo.
Os problemas aparecem tarde
Um agendador parado ou um servidor que ficou em silêncio não gera nenhum erro. Os workflows agendados simplesmente param de rodar até alguém perceber.
Alertas configurados servidor por servidor
E-mails de falha exigem configurações de e-mail e de notificação em cada servidor, mantidas em sincronia manualmente.
Cada correção exige mais um login
Repetir uma execução com falha ou aprovar uma etapa em espera significa encontrar o servidor certo, abrir a interface web dele e fazer login lá.
Nenhum acesso seguro para IA
Deixar o ChatGPT ou o Claude trabalhar em um servidor atrás de um firewall significa abrir uma porta ou entregar uma chave de API.
Um console para todos os servidores
A seção Monitoring do console Dagu tem as páginas Overview, Servers, Runs, Alerts, Notifications e Insights, além de uma página para cada servidor, workflow e alerta. Todos os membros do workspace podem visualizá-las.
Overview: o que precisa de atenção agora
Servidores enviando relatórios, falhas de hoje (UTC), execuções em andamento e a taxa de sucesso nos últimos 7 dias UTC. A lista Needs attention mostra o que aguarda uma pessoa, os alertas abertos e as falhas de hoje, cada item com sua ação na própria linha.
- Not reporting
- Not checking in
- Offline
- Scheduler stopped
- Failing workflows
- Events lost
- Monitoring off
Servers: cada servidor e seu status
Cada servidor conectado com seu status, versão do Dagu, último relatório, falhas de hoje (UTC), taxa de sucesso em 7 dias UTC e alertas abertos.
- Reporting
- Um relatório chegou nos últimos 5 minutos.
- Not reporting
- O servidor já enviou relatórios, mas não nos últimos 5 minutos.
- Not checking in
- Sem check-in de licença há mais de 26 horas.
- Offline
- Sem check-in de licença há mais de 72 horas.
- Monitoring off
- O monitoramento foi desativado no servidor, ou o console Dagu não tem nenhum relatório dele.
- Scheduler stopped
- O último relatório indica zero agendadores em execução, então os workflows agendados não iniciam.
- Events lost
- O servidor ficou sem conexão por mais tempo do que seu armazenamento de eventos retém os eventos, então algumas execuções concluídas não puderam ser enviadas.
Cada servidor: saúde e histórico recente
Uma página por servidor. A aba Overview mostra a saúde dele (versão do Dagu, SO e arquitetura, início do processo, último relatório, último check-in), os serviços do último relatório, alertas abertos e as falhas mais recentes. A aba Runs lista as execuções dele. A aba Workflows mostra as execuções concluídas de cada workflow por dia UTC ao longo de 14 dias, com execuções, falhas, taxa de sucesso e duração média e máxima.
Execuções em todos os servidores
As execuções em andamento vêm primeiro, depois as concluídas, das mais recentes para as mais antigas. Cada execução tem um link permanente para suas tentativas.
Filtre por servidor, workflow, status (failed, succeeded, running, waiting ou queued) e período: última hora, 24 horas, 7 dias, 14 dias ou, no Team e no Pro, 30 dias.
Insights: tendências de 7, 30 ou 90 dias
Execuções, falhas e taxa de sucesso comparadas ao período anterior, execuções por dia e cada workflow com sua duração p95 e como ela mudou. As execuções de hoje entram na contagem à medida que terminam.
Cada workflow: está falhando ou ficando mais lento?
Uma página por workflow com o alerta aberto, execuções por dia, taxa de sucesso e duração p50 e p95 em 7, 30 ou 90 dias, além das execuções recentes e das etapas em que ele falhou. Os proprietários podem silenciá-lo aqui.
Aja pelo console ou pela sua IA
O Dagu Cloud alcança cada servidor por uma conexão aberta pelo próprio servidor, para que membros e clientes MCP possam agir sobre execuções sem porta de entrada, VPN ou chave de API.
Aja sobre execuções no console
Leia o log de uma etapa com falha, repita ou pare uma execução e aprove ou rejeite uma etapa que aguarda uma pessoa, direto da página Overview, da execução ou do alerta correspondente.
Um endpoint MCP para todos os servidores
Conecte o ChatGPT, o Claude ou outro cliente MCP uma única vez. Ele lê execuções e logs, inicia e repete workflows e edita DAGs nos servidores do workspace, conforme a função de cada membro permitir.
Dentro dos limites de cada servidor
O administrador de cada servidor ativa o acesso remoto e define a função mais alta que ele permite. Cada chamada é assinada apenas para aquela requisição e registrada no Dagu Cloud e no próprio log de auditoria do servidor.
No Team e no Pro, ou durante um teste. Requer Dagu v2.22 ou posterior.
Como o acesso remoto funcionaUm alerta por problema, não um e-mail por execução com falha
Um alerta pertence a um workflow ou a um servidor. Ele abre uma vez, conta o que vem depois e se resolve sozinho quando o problema termina.
Um workflow falha
Uma execução com falha abre o alerta do workflow. As falhas seguintes aumentam a contagem sem nova mensagem, e a próxima execução bem-sucedida o resolve.
Um servidor para de enviar relatórios
10 minutos sem relatório, ou 25 no monitoramento gratuito, abrem o alerta do servidor, para que um host fora do ar ou um processo parado não passe despercebido. O próximo relatório o resolve.
Uma execução demora demais
Team e ProUma execução que continua rodando depois do dobro do tempo habitual do seu workflow, e pelo menos 10 minutos a mais, abre um alerta antes que alguém estranhe um relatório atrasado. Ele se resolve quando a execução termina.
- Cada alerta tem uma página com o que falhou, em qual servidor, e uma linha do tempo de quando abriu, cada e-mail e cada post, e quem o reconheceu.
- Qualquer membro do workspace reconhece um alerta na página dele, e um destinatário direto do e-mail, sem fazer login. O incidente no PagerDuty é reconhecido junto.
- No Team e no Pro, alertas que ninguém reconheceu são postados de novo a cada hora, 4 horas ou dia, até 6 vezes. Adie os lembretes por uma hora, um dia ou até as 9:00 no seu fuso horário.
- Alertas que abrem ou se resolvem juntos chegam em um único e-mail. Um canal recebe no máximo 20 posts de uma vez, e um resumo do restante.
- Execuções abortadas e rejeitadas contam como falhas nos totais, mas não abrem nem resolvem alertas.
- Os horários em e-mails e posts seguem o fuso horário do seu workspace. Um workflow barulhento pode ser silenciado: os alertas continuam registrados, mas ninguém é avisado.
Os alertas de workflow exigem o nível Health and run status. Os e-mails são enviados por no-reply@dagu.sh.
Alertas onde sua equipe já olha
Os e-mails de alerta vão para proprietários e administradores, e para os membros e endereços externos verificados que você adicionar, cada um com descadastro em um clique. No Team e no Pro, os alertas também vão para até 10 destinos: Slack, Microsoft Teams, Google Chat, Discord, PagerDuty e webhooks assinados.
- Slack
- Microsoft Teams
- Google Chat
- Discord
- PagerDuty
- Webhook
Adicionar um destino envia um teste, e cada um mantém um registro de cada post e da resposta. Um post com falha é repetido com backoff por até um dia, e um destino que recusa alertas três vezes seguidas para e avisa.
Um resumo semanal para os proprietários
Team e ProToda segunda-feira às 8:00 no fuso horário do workspace, cada proprietário recebe um e-mail que resume a semana anterior. Um link o interrompe.
- Execuções concluídas e taxa de sucesso, comparadas à semana anterior
- Alertas abertos e resolvidos, e a rapidez com que foram reconhecidos e corrigidos
- Os workflows que mais falharam e os que ficaram mais lentos
- Servidores que ficaram em silêncio e destinos que pararam de aceitar alertas
A execução e os dados ficam nos seus servidores
Seus servidores enviam relatórios ao console Dagu. O console Dagu nunca se conecta a eles e nunca executa workflows.
Apenas HTTPS de saída
Os relatórios são requisições HTTPS do servidor para console.dagu.sh. Nenhuma porta de entrada é aberta, e nada se conecta ao servidor.
Os workflows nunca esperam pelo console
Se o console Dagu estiver inacessível, os workflows rodam normalmente. O servidor tenta novamente e envia as execuções que ficaram pendentes assim que o console voltar.
Desativado até você ativar
O monitoramento vem desativado por padrão e é escolhido por servidor pelo administrador dele. Conectar ou atualizar um servidor não envia nada além do check-in de licença dele.
Três níveis
Health only envia o que o servidor executa. Health and run status adiciona o status das execuções dele e é necessário para os alertas de workflow. Um terceiro nível também envia as mensagens de erro das etapas com falha, para que os alertas mostrem por que uma execução falhou.
O que sai do seu servidor
Versão do Dagu, SO e arquitetura, e quando o processo do servidor iniciou
- Health only
- Enviado
- Health and run status
- Enviado
Número de agendadores em execução e de coordenadores registrados
- Health only
- Enviado
- Health and run status
- Enviado
Cada execução de nível superior concluída: nome do DAG, ID da execução, ID da tentativa, status, gatilho e quando foi enfileirada, iniciada e concluída
- Health only
- Não enviado
- Health and run status
- Enviado
Nomes das etapas com falha de uma execução, até 50
- Health only
- Não enviado
- Health and run status
- Enviado
Execuções na fila, em execução ou aguardando, até 200 por relatório
- Health only
- Não enviado
- Health and run status
- Enviado
Logs, saídas, parâmetros, ambiente, comandos das etapas, DAG YAML e valores de segredos
- Health only
- Nunca enviado
- Health and run status
- Nunca enviado
Todo relatório também inclui o ID da licença, o ID do servidor e o segredo de heartbeat do servidor, assim como o check-in de licença. Nomes de DAG e de etapas só são enviados com o status das execuções; escolha Health only se você os considera sensíveis. As mensagens de erro das etapas com falha só são enviadas em um terceiro nível, Health, run status, and error messages: o final de cada erro, com os segredos declarados mascarados.
Configure em três passos
Requer Dagu v2.19.1 ou posterior (v2.19.2 ou posterior para o monitoramento gratuito), e o servidor precisa acessar https://console.dagu.sh por HTTPS.
- 01
Conecte o servidor ao console Dagu
No Dagu, abra Plan & features e selecione Connect to Dagu Console, execute dagu license activate ou inicie o servidor com uma chave de servidor. Servidores com licenças offline não enviam relatórios.
- 02
Escolha o que reportar
Selecione Turn on na seção Monitoring de Plan & features e depois escolha Health and run status ou Health only. A escolha vale na hora, sem reiniciar.
Para servidores gerenciados como código, defina o nível no arquivo de configuração ou defina DAGU_CLOUD_REPORT=runs:
cloud: report: runs # off, health, or runs - 03
Veja no console Dagu
O servidor envia um relatório a cada 60 segundos e em cerca de 5 segundos quando uma execução falha ou as execuções em andamento mudam. Ele aparece em Monitoring no console Dagu.
Planos, retenção e limites
O que cada plano cobre, por quanto tempo o Dagu Cloud guarda o que os servidores reportam e quanto ele armazena por dia.
Planos
Grátis para um servidor por workspace, com limites menores: um relatório a cada 5 minutos, 100 execuções armazenadas por dia, 7 dias de histórico de execuções e e-mails de alerta para proprietários e administradores. Team e Pro cobrem cada servidor licenciado, com 30 dias de histórico, destinos de chat, PagerDuty e webhook, lembretes, alertas de execuções longas demais e o resumo semanal.
Comparar planosRetenção
- Execuções concluídas
- 30 dias
- Totais diários por workflow
- 13 meses
- Alertas resolvidos
- 90 dias após a resolução
- Alertas abertos
- Até serem resolvidos
O monitoramento gratuito mostra as execuções concluídas dos últimos 7 dias, e um teste as dos últimos 14. Um servidor que fica 30 dias sem enviar relatório é removido do monitoramento, com seus totais diários e alertas.
Limite diário de execuções
Cada workspace armazena até 500 execuções concluídas por dia UTC, ou 100 no monitoramento gratuito. As execuções acima do limite continuam sendo contadas nos totais diários e continuam abrindo e resolvendo alertas, mas não são adicionadas à lista de execuções. O armazenamento é retomado às 00:00 UTC.
Precisa de mais? Fale conoscoOpere todos os servidores Dagu de um só lugar
Leia o guia de configuração ou abra o console Dagu e conecte seu primeiro servidor. Grátis para um servidor; inicie um teste do Team ou do Pro.