Skip to content

About

A path every data team builds, and nobody should have to build again.

DataRunner started from a repeated chore: someone writes the query, exports a spreadsheet, attaches it to an email, and repeats every Monday until they forget.

01

The problem

The query is the easy part, and the only part that needs knowledge of the business. Everything else — running on time, formatting, attaching, delivering, raising the alarm when it failed, keeping a record of what was sent — is plumbing, and that is where the time goes. Large teams solve it with a cron job, a script and a bucket; small teams solve it with a person remembering. Both break quietly.

02

The choice

Automate the whole of the plumbing and touch none of the query. You write SQL, which you do better than any tool can guess. DataRunner handles the schedule, the format, the channel, the history, and the alert when a run fails.

03

Why monitoring came with it

Anyone depending on an automated report needs to know when it did not arrive — and the cause is almost never the report. It is the database that went down, the endpoint that got slow, the server that ran out of disk. Watching endpoints and servers in the same place the report is scheduled was not scope creep; it was the rest of the same problem.

04

How we work

We publish what is finished and say what is not. Connectors that have never run against a live instance are marked beta in the product itself. Desktop platforms we are not building are not offered. It is slower to write and it is the only way documentation keeps being worth anything.

Where we are today

23
Databases that run queries
6
Databases watched for availability
4
Delivery channels
2
Product languages

The best way to judge it is to connect a database.

The free plan has no expiry and asks for no card.