Monitoring only works when someone acts on it. On a small data team that someone is one person, and the window is the twenty minutes between opening a laptop and joining standup. If clearing the overnight findings takes longer than that, it stops happening — first on busy days, then on most days, until the digest is something everyone filters into a folder. So the routine has to fit the window: read in severity order, verify rather than re-derive, close every finding with one of three outcomes, tell the right person.

Minutes 0-2: read Critical first, and only Critical

Open the digest and read only the Critical findings — not the Warnings, not the Info, not the summary of what was scanned. Severity ordering exists so you can stop reading partway down, and actually stopping is what keeps the routine inside its window. Count them:

Zero. Skim the Warnings, close the tab, go to standup.
One or two. Normal, and what the rest of this playbook is written for.
Five or more on unrelated tables. Almost never five independent problems. It is one upstream cause — a load that did not finish, a credential that expired, a pipeline that failed silently at 2am. Look at the loader first; triaging fanned-out symptoms one by one is the most reliable way to spend an hour and learn nothing.

Minutes 2-8: verify the claim, do not re-derive it

When a tool says orders had 200 rows yesterday instead of the usual 10,000, the instinct is to count the rows yourself. Resist it: you are not checking whether the tool can count, you are checking whether the count means what the finding says it means. A good finding hands you the queries it ran, sample offending values, and the baseline it judged against — ask a different question of each.

The query — is it asking the right question? Does the date filter match how the table is partitioned, and cover the full load window rather than cutting off at midnight for a table that loads at 3am? A volume drop is often a query that ran too early.
The samples — data problem or business event? Twelve order_id duplicates that are all one value are a broken join. Twelve from one merchant on one afternoon are a retry storm at the source. Different owner.
The baseline — is normal still normal? Where most false alarms die: a bank holiday, a campaign that ended, a backfill that inflated the last three weeks. A baseline learned over a period that no longer represents the business is right about the numbers and wrong about the world.

If one of the three fails, you know which, and that is what you write down. The only query worth running yourself is not “is this true” but “what else does this touch”:

-- does the duplication change the number on the dashboard?
select sum(order_value)                       as revenue_as_reported,
       sum(order_value) filter (where rn = 1) as revenue_deduplicated
from (
  select order_value,
         row_number() over (partition by order_id order by loaded_at) as rn
  from analytics.orders
  where order_date >= current_date - interval '7 days'
) t;

Matching figures mean a cosmetic duplicate and a note. A six percent gap means a wrong dashboard and a message to write.

Minutes 8-11: three outcomes, no fourth

Every finding you opened gets closed before you move on. “Leave it and see if it comes back tomorrow” is how a digest silts up until nobody reads it.

Resolve. Real, and now understood — whether or not the fix has shipped. The finding records that a human looked; the ticket carries the work.
Mute, with a reason and an expiry. Correct observation, not actionable now: the migration lands on the 14th. An indefinite mute is a deleted check with extra steps, and the check you silence in March is the one that fires in September when it matters.
Mark as expected. Normal behaviour, wrong baseline: weekend volume genuinely is a tenth of weekdays. The only outcome that changes future scans, so be deliberate — mark expected when you would be annoyed to see it again, mute when you would be relieved to.

The common mistake is muting what should be marked expected, because muting feels lower-commitment. It is the same decision with worse memory.

Minutes 11-15: tell someone, in their language

If a number people look at is wrong, the work is not done when the ticket is filed — someone will open that dashboard this morning and decide something on it. The message needs four things: what is wrong, since when, what it means for them, when it will be right. Skip the mechanism; nobody outside the team needs the join fan-out.

Heads up: the revenue dashboard has been overstating since Tuesday.

Daily revenue is roughly 6% too high for 12-14 August: order records were loaded twice on those days, so some orders are counted more than once. Order counts are affected the same way; everything before 12 August is correct.

A fix is in progress and I expect corrected figures by end of day Thursday. If you have already shared those numbers externally, tell me and I will get you the corrected version first.

One number, one date, one action for them. Send it to the people who use the number — the pipeline owner gets the ticket — and send it before someone else notices.

Ticket or note? A ticket if fixing it requires changing code, a note if it requires changing understanding. A join that fans out or a loader with no retry: ticket, with the evidence pasted in so nobody re-derives it. A one-off bad file, a genuine spike, a baseline that needs to relearn: note. If you cannot decide, ask whether you would be annoyed to see it again in a month.

When to stop and escalate

Fifteen minutes is a budget, and blowing through it is information. Get help when:

One finding has eaten ten minutes and the story keeps changing. The problem is upstream of where you are looking.
The fix touches something you cannot roll back — a backfill over a live fact table, a column other pipelines read.
The blast radius includes anything already sent outside the business — invoices, an investor deck, anything regulatory. Whoever owns that relationship belongs on the thread.
The same finding has fired three mornings running. A standing problem handled as a daily interruption; it needs an owner and a date.

The trap: fixing symptoms in the warehouse by hand

At 9:20 with standup in ten minutes, the tempting shortcut is to fix the number rather than the cause: delete the duplicate rows, default the nulls, re-run one day’s load by hand and move on.

Don’t. The pipeline is unchanged and will produce the same rows tonight, but the evidence is gone and the baseline has learned the table is fine. You have not fixed the problem, you have hidden it from the only thing watching for it. Six weeks later a colleague finds a gap between the warehouse and the source system and loses a day to it, because nothing records that a human once typed a DELETE.

If a number must be corrected today, correct it in the pipeline and reload. A manual edit with no paper trail is a landmine laid for whoever comes next.

How Sentry handles it

Sentry is built to make this fifteen minutes possible, not to do the triage for you.

One email, ordered by severity, so “read Critical first and stop” is the default path rather than a discipline you impose. Findings deep-link into the dashboard.
Evidence on every finding — the queries run, sample offending values, the baseline it was judged against — because verifying in seconds keeps the routine short.
Exactly the three outcomes above: resolve, mute or snooze for a chosen period, or mark as expected, which folds the pattern into the baseline. Scale and Ultra add a per-table sensitivity dial.
Baselines that know your rhythms, learned per table, so seasonal false alarms mostly never reach you.
Never a fix. Sentry reads and diagnoses; it cannot write to your warehouse, by design. Deleting a row or reloading a day stays with the person who understands the pipeline.

Plans and limits are on the pricing page.

Want a digest you can clear before standup? Pick a plan and get started — read-only credentials, first digest tomorrow morning.

A fifteen-minute triage playbook for the morning digest