The week, in one line
At the top of Sources you will find one sentence about the window behind you — seven days — and it says one of three things.
The middle row is the one worth knowing about. A week with no findings and a
source that has gone quiet is not a quiet week — it is a week the product
cannot vouch for, and the line says how many sources it cannot vouch for it
on. Which ones, and why, is on their own rows below — see the next section.
Zero findings is never shown on its own
Under that line, every source shows the age of its last stored signal, per kind — errors and deploys separately, in every state, including the healthy ones. That is deliberate and it is the whole point of the screen. A source that looks healthy over a three-day-old age is exactly what a silently paused integration looks like, and hiding the age in the good state is how one goes unnoticed for a whole week. So the ages are always on screen, next to the verdict, and you can compare them to your own clock. The limits after which a source stops describing itself as storing:
Neither has been measured against real traffic. They are printed on the screen
so that the day one of them is wrong, you can see it rather than take it on
trust.
What a silence proves depends on who sent it
The two vendors are not the same, and the screen does not average them.GitHub — a silence is evidence
A repository webhook fires on every push, every deployment and every deployment status, unthrottled. A repository that has said nothing for longer than its limit has stopped, and the screen says so, names the kind, and states the age.Sentry — a silence is not evidence
On the route we recommend and document, Sentry reports an issue the first time it appears and at most once every 30 minutes per issue afterwards. It reports nothing at all when nothing is firing. How quiet a perfectly healthy Sentry source is therefore depends on a rule inside your Sentry account, and on whether anything is going wrong. So a Sentry source past its limit is shown as quiet — neither health nor an alarm. Its age is stated, it is never marked as a fault, and no sentence on it suggests anyone did anything wrong.Every quiet Sentry source carries the same sentence, not just the ones that look suspicious: an
alert rule still in place on a product with nothing going wrong, and an integration deleted at
Sentry, produce identical evidence here — nothing at all — and the product cannot tell which one
it is looking at.
Two things a quiet reading might really be
The screen says both of these on itself, where the reading is, rather than leaving them here. A rotated secret looks exactly like quiet. Deliveries are verified against the secret on the source. If your Sentry Client Secret is regenerated, or a GitHub webhook secret is changed on your side, the next delivery is refused — and until something actually fires, there is no next delivery. Between the rotation and the next event, a rotated source and a genuinely quiet one are identical from here, and the product cannot tell them apart. When a delivery does arrive and is refused, the source moves to Arriving but refused, which says so on the row and tells you which secret to replace. Delivering and storing nothing is a different problem. A source that is receiving deliveries while storing none of them shows as Delivering, storing nothing — a distinct state, with distinct words, listing the delivery types that arrived beside the ones we read. It is not a silence: every delivery-level indicator is green and no evidence is being collected at all, which is why it is the loudest state on the screen. Receiving nothing and receiving-but-storing-nothing are never shown the same way. One is a disconnection, the other a misconfiguration, and they send you to two different places.The one quality figure
Beside the verdict is the share of the errors stored this week that carry no usable release. A release is usable when the error names one and a deploy we have stored matches it. Errors without one still produce findings — weaker ones, that cannot say which build they followed. It is a proportion rather than a count on purpose: it is a quality figure, not an outage. And it is a question asked of the stored deliveries each time it is read, not a verdict stamped on the row when it arrived. That has two consequences worth knowing:- The number can be corrected backwards. We keep the raw body of every delivery, verbatim. When we get better at reading a release out of it, the figure for weeks already behind you improves too.
- A deploy that arrives late still counts. The matching deploy sometimes reaches us seconds after the error it explains. Because the match is made at read time, the error stops being unattributable the moment the deploy lands.
What this screen still cannot tell you
It reads what your sources can answer, and no more:- Whether a rule inside our product has run at all
- Whether a daily ceiling on findings was reached
- Whether a source is still inside its establishing window