Frigate person/car Telegram alerts had been silently dead for ~17 days (since exactly 2026-07-29 13:01:15). The obvious-looking cause — Event dropped - Already notified on this zone flooding the logs — was a red herring. The real cause was that Docker containers on telep-mainframe lost external DNS the moment the host resolver became Tailscale MagicDNS (100.100.100.100), so frigate-notify could no longer resolve api.telegram.org and every send failed. Fixed by pinning an explicit dns: on the frigate-notify service. See Alerting, 2026-07-28-frigate-notify-camera-exclude, 2026-08-15-telep-lan-split-horizon-caddy.
For Agents
Symptom: no alerts in Telegram group Telephely biztonsági riasztások (chat_id -1004475187307, bot @tlphlyortbot “Dezsi az őr”) despite cameras live on the wall.
Dead since:2026-07-29 13:01:15 (last Alert sent in frigate-notify logs) — ~17 days, unnoticed (there is no failure alarm).
Root cause: host /etc/resolv.conf = nameserver 100.100.100.100 (Tailscale MagicDNS). Docker’s embedded DNS (127.0.0.11) forwards container external lookups to that upstream, and MagicDNS “misbehaves” for containers → containers can’t resolve public names. Something enabled/changed Tailscale DNS (--accept-dns / MagicDNS) on 2026-07-29.
Fix (applied): add explicit dns: [192.168.1.1, 1.1.1.1] to the frigate-notify service in /home/levander/nvr/docker-compose.yml, then docker compose up -d --force-recreate frigate-notify. Backup at docker-compose.yml.bak-dns.
Verify:docker logs --tail 200 frigate-notify | grep 'Alert sent' shows fresh provider=Telegram sends; zero server misbehaving.
Symptoms
A camera was visibly live on the camwall but “alerts aren’t firing” — no person/car Telegrams arriving.
frigate-notify logs were flooded with, every 15 s poll:
Event dropped - Already notified on this zone zones=
Review dropped - No events eligible
The zones= field was empty, which looked exactly like a zone/deduplication misconfig.
ZeroAlert sent lines since 2026-07-29 13:01:15.
The red herring — “Already notified on this zone” is NOT a dedup/zones bug
A failed Telegram send masquerades as deduplication
frigate-notify (events/reviews.go + events/filters.go) caches a detection during filtering, BEFORE the Telegram send. The cache (events/cache.go) is an otter cache keyed by event ID with a 1-HOUR TTL.
When the send fails, the event stays cached. So every subsequent 15 s poll sees that event ID already in the cache → logs Already notified on this zone (with empty zones=) and the review loop breaks → Review dropped - No events eligible.
A failed send therefore looks identical to over-aggressive dedup. Chasing zones/dedup config here is wasted effort — the cache entry is a symptom of a delivery failure, not a cause.
Actual root cause — Docker container external DNS
Tailscale MagicDNS on the host silently kills external DNS for every Docker container
The real error was buried in WRN lines, only visible with:
docker logs --tail 4000 frigate-notify | grep WRN
Unable to send alert error="Post https://api.telegram.org/bot.../getMe:
dial tcp: lookup api.telegram.org on 127.0.0.11:53: server misbehaving"
Why: the mainframe host /etc/resolv.conf is:
nameserver 100.100.100.100
search taild4189d.ts.net local lan
100.100.100.100 is Tailscale MagicDNS. Docker’s embedded resolver (127.0.0.11:53) forwards a container’s external lookups to that host upstream. tailscaled intercepts 100.100.100.100 locally for the host, but a container forwarding to it fails → server misbehaving.
Proof:docker exec frigate curl -s -o /dev/null -w '%{http_code}' https://api.telegram.org returned 000 (DNS failure), while the same curl from the host worked. Something enabled/changed Tailscale DNS (--accept-dns / MagicDNS) on 2026-07-29, which lines up exactly with the last successful alert.
Everything else was healthy — only container DNS was broken
Ruled out, all confirmed fine during the outage:
Component
Check
Result
Telegram bot
getMe / getChatfrom the host
OK — bot still in the group
Snapshots
snapshot.jpg?bbox=1
200
frigate-notify config
labels allow person/car, zones.unzoned allow, no min_score
OK
Frigate itself
detections firing, events in DB
OK
Container external DNS
docker exec frigate curl https://api.telegram.org
http=000 ← the one broken thing
The fix (applied)
Add an explicit resolver to only the frigate-notify service in /home/levander/nvr/docker-compose.yml:
docker compose up -d --force-recreate frigate-notify
Backup at docker-compose.yml.bak-dns.
Docker’s embedded DNS still resolves the internal frigateservice name — only external lookups now use the new upstream, so nothing internal breaks.
Result — instant recovery
Immediately after the recreate, INF Alert sent ... provider=Telegram fired for cam1 and cam2, and there have been zero server misbehaving errors since.
Gotchas to remember
1. Any container needing EXTERNAL DNS silently fails while the host resolver is Tailscale MagicDNS
As long as the host /etc/resolv.conf points at 100.100.100.100, any Docker container that must resolve a public name will silently fail. frigate-notify is the one that bit us (needs api.telegram.org). Most other containers on this box only need internal / service-name resolution, so they were unaffected. Host systemd services (e.g. intruder-alarm.py) use the host resolver directly and are fine — this is a container-only failure.
2. Broader/durable fix (deferred, note as an option)
A daemon-wide fix is to set in /etc/docker/daemon.json:
{ "dns": ["192.168.1.1", "1.1.1.1"] }
(the file currently only carries the nvidia runtime) and restart docker — but that restarts ALL containers, so it was deferred in favour of the targeted per-service dns: fix. Apply the daemon-wide version if more containers start needing external DNS.
3. Diagnostic tip — dedup flood with zero "Alert sent" = look for a buried WRN
If frigate-notify logs are full of Already notified on this zone and there are noAlert sent lines, do not chase dedup/zones config. Instead:
docker logs --tail 4000 frigate-notify | grep WRN
and look for Unable to send alert / server misbehaving — it’s a DNS / delivery failure, not a filtering misconfig.
Scope note — which cameras alert, and the removed Xiaomi
Alerts are wanted only on the DÉL / South cameras — 192.168.30.119 = telep_cam1 (DÉL – Fix) + telep_cam2 (DÉL – PTZ). These are not excluded.
The ÉSZAK / North camera (192.168.30.139 = telep_cam3 / telep_cam4) stays in frigate-notify’s frigate.cameras.excludeon purpose (aimed indoors, spammy) — see 2026-07-28-frigate-notify-camera-exclude.
The Xiaomi C302 (192.168.30.168) has been REMOVED — that IP is now dead. Any note still calling .168 a live camera is stale (the 2026-08-09-xiaomi-c302-tailnet-facetime-cam note describes a device that no longer exists). Note also that the Xiaomi was the only camera that ever used the separate go2rtc-cam path — the Tapo cams go direct RTSP into Frigate, not through go2rtc-cam.
Related minor fix — OliveTin “Kamerák” action pinged a dead IP
The admin portal OliveTin “Kamerák” action was pinging a wrong/dead IP (192.168.30.168, the removed Xiaomi). Corrected to ping the two live camera hosts: .119 (DÉL) and .139 (ÉSZAK).
A canary for this exact outage now exists
The [[2026-08-15-admin-portal-passkey-olivetin#olivetin-self-test-telep-selftest—2026-08-15-refactor|telep-selftest alerts]] section (OliveTin action “Riasztások (Telegram)”) probes for THIS failure: it runs docker exec frigate curl https://api.telegram.org (the precise container-DNS check), reports the last “Alert sent” timestamp, and counts misbehaving DNS errors in the last 30 min. Run it after any Tailscale/DNS change to confirm alerting still works.
Related
Alerting — the frigate-notify → Telegram “Dezsi az őr” alerting path (updated with this incident)