When revenue drops,
Revenue is one example. Metron works on any number in your warehouse that changes over time. It finds the segment that moved and writes up the evidence in plain language. Your data stays where it is.
The dashboard shows the drop. Someone still has to find the reason.
You know the routine. Someone spots a number that looks off and asks about it in Slack. An analyst slices it by region, then by platform, and asks around to learn what shipped that week. The answer arrives a day later, and only for the metrics someone was watching.
Metron runs that same investigation on each metric you give it, each time it moves.
By hand
27h 40m- Someone notices a number looks off and asks in Slack.
- An analyst drops planned work to look into it.
- The analyst has sliced three dimensions. One looks suspicious.
- The analyst asks four teams what shipped last week.
- One team replies with a likely cause.
Answer arrivesTuesday afternoon
With Metron
3 min- Metron's scheduled check finds a change outside the metric's normal range.
- Metron tests each segment. Most of the change sits in one.
- Metron finds one logged event close to the start of the change.
- Metron posts the write-up in your team's channel.
Answer arrivesMonday, 09:03
This timeline is an example. Your run time depends on your warehouse and how many segments you ask Metron to test.
If you can query it, Metron can investigate it.
Metron has no list of supported metrics. To Metron, a metric is a number, a timestamp, and the columns you would slice it by. Define that once. Metron learns the metric's normal pattern and investigates when it moves.
Pick a field below. The engine is the same in each one, and only the definition changes.
- Value
- count(activated) / count(signups)
- Time
- signed_up_at
- Slice by
- signup_method, plan, country
- Events
- GitHub releases
That is the whole setup for one metric.
Activation rate is 9.4% below expected since Wed 10:00 UTC. 68% of the drop is signups through Google SSO. Their activation fell from 41% to 29%. Release auth-service 2.14 went out 52 minutes before the drop began.
- Value
- count(refunds) / count(orders)
- Time
- ordered_at
- Slice by
- fulfillment_center, category, refund_reason
- Events
- Ops log
That is the whole setup for one metric.
Refund rate is 31% above expected since Monday. 64% of the rise comes from the Leeds fulfillment center, where "wrong item" refunds doubled. Ops logged a pick-list template change one day before the rise began.
- Value
- count(approved) / count(attempts)
- Time
- attempted_at
- Slice by
- card_network, country, acquirer
- Events
- GitHub deploys
That is the whole setup for one metric.
Card authorization rate is 3.1 points below expected since 14:00 UTC. 77% of the drop is Visa debit cards in Brazil, all routed through one acquirer. Deploy routing-rules v88 went out 24 minutes before the drop began.
- Value
- count(on_time) / count(deliveries)
- Time
- delivered_at
- Slice by
- hub, carrier, service_level
- Events
- Ops log
That is the whole setup for one metric.
On-time delivery is 6.2 points below expected since Thursday. 71% of the drop is the North-East hub. No carrier got slower there. A larger share of parcels now goes to the slowest one. Ops logged a carrier contract switch two days before the drop began.
- Value
- sum(scrapped_units) / sum(units)
- Time
- produced_at
- Slice by
- line, shift, part_number
- Events
- Quality log
That is the whole setup for one metric.
Scrap rate is 1.8 points above expected since Tuesday, second shift. 74% of the rise comes from Line 4, on part number 88-2104. Quality logged a supplier lot change six hours before the rise began.
- Value
- avg(minutes_to_seen)
- Time
- arrived_at
- Slice by
- site, shift, triage_level
- Events
- Ops log
That is the whole setup for one metric.
Average ER wait is 22 minutes above expected since Monday. 66% of the rise is the night shift at the Riverside site. Ops logged a new triage form rollout nine hours before the rise began.
Your metric goes in the left box. If SQL can aggregate it and a timestamp column dates it, Metron can watch it. Metron doesn't need to know what the number means to tell you where it moved.
Each investigation runs the same four steps.
An investigation starts one of two ways: Metron notices a change, or someone asks a question. Both return the same evidence.
Walking through activation_rate from the example above. Pick a different one
Checks the move against the metric's own normal.
Metron removes the weekly pattern and the trend before it judges anything, so a Monday dip or a holiday lull doesn't count as a change. Most alarming moves are normal variance, and Metron says so. A new metric gets a simpler model until it has enough history.
Finds where the change sits.
Metron tests each segment of each column you listed against that segment's own history. You learn which segment holds most of the move. Metron also tells you whether the rate changed or the mix behind it shifted. You fix those two in different ways.
Puts the change next to what happened.
Deploys and releases arrive from GitHub by webhook. You log the rest yourself, from a price change to a new supplier. Metron checks which events fall close to the start of the change, so you skip the “did anything ship Tuesday?” thread.
Explains it to someone who wasn't there.
You get a few plain sentences with the numbers in them. The language model only words what the engine measured. It sees the findings and nothing else, which leaves it no room to invent a reason.
Activation rate is 9.4% below expected since Wed 10:00 UTC.
After the write-up
Ask a follow-up
Ask a follow-up and Metron answers from the same evidence. It doesn't start a fresh guess.
Send it where your team looks
You switch on webhook or email per metric. Point it at the channel or pager your team watches.
POST /hooks/metron 200 OK
email to [email protected] sent
Mark it useful or not
Metron stores your verdict with the evidence behind it. Over time you build a record of which alerts held up and which wasted your morning.
Metron tells you what it doesn't know.
Each finding makes three claims that deserve different amounts of trust. Metron scores each one on its own.
68% of the drop is signups through Google SSO. Their activation fell from 41% to 29%.
The segment that moved, and how much of the change it explains. Metron measures this against the segment's own history.
Release auth-service 2.14 went out 52 minutes before the drop began.
An event landed near the start of the change. That is a coincidence in time, and Metron labels it as one.
auth-service 2.14 caused the drop.
The event caused the change. Warehouse data can't prove that, so Metron leaves the sentence out and you make the call.
Point it at the warehouse you already run.
Metron queries your warehouse directly. There is no replication pipeline to build and no second copy of your data to keep in step.
Define metrics and run detection today.
Define metrics and run detection today.
Connect and browse your schema now. Running metrics on it comes next.
On the roadmap. Tell us if this is the one you run.
On the roadmap. Tell us if this is the one you run.
Running something else? Metron needs SQL and a timestamp column, so most warehouses are a connector away. Say which one in the form below and it moves up the list.
Metron is in private beta.
We are setting up a small number of teams by hand. If you have a warehouse and a metric your team can't explain, tell us about it.
Which warehouse you run and one metric you want Metron to watch. That is enough to start.
What you need
- A warehouse
- PostgreSQL or BigQuery today. Snowflake, Redshift and Azure Synapse are on the way.
- A read-only connection
- A role that can SELECT the tables behind your metric. Metron never writes.
- An LLM endpoint
- You supply it. Metron sends it the engine's findings and nothing else.
Ask your warehouse why.
Private beta. Tell us your warehouse and one metric, and we will get back to you.