This tab answers one question: how long each thing takes, and since when. It sits next to Uptime because the two are the same family — "is it up?" and "is it fast?" — and switching screens to compare them would lose the comparison.
There are two lists. On top, meulog's own scheduled jobs; below, the operations of the applications reporting to it.
meulog measures itself
The top list needs no configuration at all. Every job run has always been timed on
the monotonic clock by ApplicationJob; what was missing was someone
reading that number as performance rather than as "did it run or not". If meulog is
running, this list has content.
Your applications' operations
The bottom list arrives over the Sentry protocol, and this is where the leverage is: anyone already reporting errors through an official Sentry SDK needs no new SDK and no instrumentation. Just turn on performance tracing in the SDK that is already there:
Sentry.init do |config|
config.dsn = "https://meulog_p_F8_cLuNlSLQu1d2KSSXsCw@meulog.minhasuite.com/monde/2"
config.traces_sample_rate = 0.1 # 10% of transactions is plenty
endThis works for Ruby, JavaScript, Python, Java, .NET, PHP and Go — every official SDK speaks the same protocol.
One number: how long it took. The span tree, cross-service correlation and the call cascade are distributed tracing, which remains a different tool — if your team needs that, run it alongside. What stays here is the duration, and that is where the P95 comes from.
Why P95, and not the average
For the same reason Uptime shows the median: one thirty-second run among a thousand of two hundred milliseconds lifts the average and hides the normal. The P95 answers "how bad does it get when it gets bad", which is the question of whoever got woken up.
The Typical column is the P50 and answers a different question — "how it usually is". When the two drift far apart the operation is erratic; when they track each other it is consistent, fast or slow.
Measurements are not stored one by one: they are counted into time bands. That is what makes it possible to consolidate a day into a single row and keep the curve alive after the detail is purged — bands add up, and there is no such thing as an average of percentiles.
The price is an error bar: measured against the true percentile, it is off by less than 2.5%. Anyone needing the exact number needs the raw data, and the raw data does not survive thirty days.
The thirty-day strip
One mark per day, and the reference is the operation itself, not a fixed threshold. A nightly job that always takes forty minutes is not slow — it is what it is. What the mark shows is the day it took twice as long as usual. A day with no runs at all stays hollow, because "did not run" is different from "ran fast".
The alert
When the last hour's P95 goes past twice the seven-day baseline, an
operacao_lenta event fires and reaches every channel you have turned
on under Parts and records.
Five brakes hold back the noise, and it is worth knowing them before concluding the alert is broken:
- Absolute floor. A 4 ms operation that went to 9 ms doubled, and nobody cares.
- Minimum volume. The P95 of three samples is the third sample.
- Seven-day baseline. One bad hour does not move the reference.
- Two consecutive passes. Latency oscillates around any threshold; alerting on the first would mean alerting and un-alerting all afternoon. It is the same care a watched URL takes in requiring two failures.
- Per-operation silence. The same interval that applies to errors.
There is no "back to normal" alert, and that is on purpose: uptime is a step function — up or down — but latency is continuous, and the round-trip pair would fire every time the number grazed the threshold.
How long this is kept
The five-minute detail — the performance windows — goes after thirty days, and each day's summary stays. In other words: "how long did this screen take in March" still has an answer long after March's measurements have been deleted. The retention is set under Settings.