DataTugPull more from your data
Open app
☰

For data and platform engineers

Catch data problems before customers do

Most data problems have happened before. DataTug is building the way to keep the query that found one, run it again, and flag it before the next customer has to ask.

Explore the demo project All five solutions

Starts here: SRE and on-call

Also useful: Developers (also useful)Helpdesk (also useful)Security and compliance (also useful)Data analysts (also useful)+2 roles

Watercolor of a lighthouse keeper’s logbook on the window sill, with bell buoys marking known rocks in the bay beyond.
Watercolor at dusk: the lighthouse lamp is out, a small boat scrapes an unmarked rock where a buoy should be, and a person on the pier points at it.

The problem

Infrastructure monitoring says the services are up. It does not say that an order was paid and never booked with the carrier. That shows up as a customer complaint, then an investigation, then a fix.

A month later the same mismatch is back. The query that found it the first time is in a closed ticket or a script on someone’s laptop, run when somebody remembers.

Before and after

Who: Data and platform engineers

Today

4 tools1 hand-offno shared password

  1. A customer · Support ticketFind out from a customer that data is wrong.
  2. Whoever remembers · SQL scriptsKeep a folder of SQL scripts and run them when someone remembers.
  3. On-call · SQL clientRediscover the same mismatch after every recurrence.
  4. The team · WikiWrite the rule down in a wiki nobody reads.
Today4 tools · 1 hand-off · no shared passwordFind out from a customer that data is wrong.Keep a folder of SQL scripts and run them when someone remembers.Rediscover the same mismatch after every recurrence.Click to see

With DataTug

1 workspace0 hand-offsno shared password

Some steps are planned or in development.

  1. EngineerTurn a query into a Check with an expected outcome: rows, a set, a total.Reusable ChecksIn development
  2. EngineerDescribe what a valid record is once, with Validators, and test records against it.Reusable ChecksIn development
  3. Watch, plannedWatch runs Checks on a schedule or when data changes.WatchPlanned
  4. InvestigationA failed Check raises an observation with its evidence, and is meant to open an investigation.Observations grounded in your dataIn development
With DataTug1 workspace · 0 hand-offs · no shared passwordTurn a query into a Check with an expected outcome: rows, a set, a total.Describe what a valid record is once, with Validators, and test records against it.Watch runs Checks on a schedule or when data changes.Click to see

Each step names the part of DataTug it relies on and that part’s status today. “Planned” and “In development” steps describe where the product is going, not what you can use now.

Where it meets the other solutions

Illustrative · what a failed Check is meant to raise, not a capture

The cause behind order 11045, spotted the next time

Check failed · paid-but-not-booked

Order 11082 has a captured payment and no carrier booking after 24 hours.

Payments
captured
Carrier API
booking: none
Found by
the query from the order 11045 investigation
  • The Check and its expected outcome. Reusable ChecksIn development
  • Watch runs it on a schedule. WatchPlanned
  • A failure raises an observation with its evidence. Observations grounded in your dataIn development

Try it on sample data

The public demo project opens in the browser with sample Northwind and Chinook data. No sign-up.

Explore the demo project