Sobre
Um caminho que todo time de dados constrói, e ninguém deveria construir de novo.
O DataRunner nasceu de uma tarefa repetida: alguém escreve a consulta, exporta para uma planilha, anexa num e-mail e repete toda segunda-feira até esquecer.
O problema
A consulta é a parte fácil e é a única que exige conhecimento do negócio. O resto — rodar no horário, formatar, anexar, entregar, avisar quando falhou, guardar o que foi enviado — é encanamento, e é onde o tempo vai. Times grandes resolvem com um cron, um script e um bucket; times pequenos resolvem com uma pessoa lembrando. Os dois caminhos quebram sem avisar.
A escolha
Automatizar o encanamento inteiro e não tocar na consulta. Você escreve SQL, que é o que você sabe fazer melhor do que qualquer ferramenta pode adivinhar. O DataRunner cuida do horário, do formato, do canal, do histórico e do alerta quando a execução falha.
Por que monitoramento veio junto
Quem depende de um relatório automático precisa saber quando ele não chegou — e a causa quase nunca está no relatório, está no banco fora do ar, no endpoint com latência ou no servidor sem espaço em disco. Monitorar endpoint e servidor no mesmo lugar em que o relatório é agendado não foi expansão de escopo: foi o resto do mesmo problema.
Como trabalhamos
Publicamos o que está pronto e dizemos o que não está. Os conectores que nunca rodaram contra uma instância real aparecem marcados como beta no próprio produto. As plataformas de desktop que não estão sendo compiladas não são oferecidas. É mais lento de escrever e é a única forma de a documentação continuar valendo alguma coisa.
Onde estamos hoje
A melhor forma de julgar é conectar um banco.
O plano gratuito não tem prazo e não pede cartão.