Wikielele. DNS · self-hosted DNS analytics
docs for
back to the dashboard

The first hour

What backfill is doing, why the numbers keep moving, and when to start trusting them.

everyoneAssumes a home network and that you have heard of DNS.page 4 of 24

A fresh install looks broken for about ten minutes and then looks thin for about a day. Both are expected, and the interface tries to say which is happening.

Minute zero: backfill#

Neither resolver offers a plain “everything after time T” query that this can rely on, so the only way to read its log is backwards from now. On first run the poller walks back through the entire , a page at a time, until it either runs out of entries or reaches the oldest thing the resolver still holds.

That usually takes a few minutes and yields a few hours of history: however much the buffer happened to be holding. It is the only history that will ever exist for the period before you installed this, so it is worth letting finish.

How much that is depends on querylog.size_memory in AdGuard Home’s own config — a count of entries, not a span of time, which is why a busy house gets fewer hours out of it than a quiet one.

On Pi-hole it depends on FTL’s MAXDBDAYS and on how much of the in-memory window it still holds. FTL keeps its own long-term database, so the first walk backwards often returns rather more than AdGuard Home’s buffer would — but it is still a fixed window that overwrites, and it is still the reason this product exists.

← backfill, onceinstallcatch-up, every 5s →
Backfill reaches left into whatever the resolver still holds and then stops for good, because there is nothing older to find. Catch-up extends to the right forever. The gap on the far left is history that was overwritten before this was installed, and no amount of waiting recovers it.

Minute one onwards: the poll loop#

Every five seconds the worker asks for the newest page and walks back until it reaches the , which is the newest row already stored. On a normal household that is one request returning a handful of rows.

What you seeWhat it means
The dot in the top bar is green and beatingRows are arriving. Everything is fine
“still backfilling” in the coverage noteThe first walk backwards has not finished yet
A lag figure in minutesIngest has fallen behind. Usually the resolver restarted
Empty charts, green dotIngest works, and your router is not using this resolver yet

Hour one: the pages start working#

Different screens need different amounts of history before they say anything useful:

PageUseful afterWhy
OverviewMinutesTotals and the live stream need almost nothing
DestinationsMinutesNeverEvery resolved answer is a point on the mapPi-hole’s log carries no answer addresses, so the page is hidden rather than empty
ExplorerMinutesIt is the rows themselves
DevicesHoursThe rhythm chart is by hour of the week
FrictionHoursRetry episodes need repeat behaviour to group
AnomaliesDaysEvery detector compares against a baseline it has to have

The anomaly detectors say so themselves rather than reporting a confident nothing: a detector without enough history to be meaningful reports that it could not run, which is the design principle those pages are built on.

Day one: retention starts mattering#

Nothing is deleted until rows are older than RETENTION_DAYS, which defaults to 90. When that day comes, detail is pruned and the hourly behind it are kept forever, so the long ranges keep answering. Rollups and retention covers what survives.

See also