Download graph misrepresents outages by connecting snapshot points

[Kletternaut]

Bug Type

UI or visual issue

Affected Area

Monitoring dashboard

DOCSight Version

Latest release

Exact Version or Commit

No response

What happened?

The Download graph in DOCSight falsifies the real situation by connecting measurement snapshots with lines.
Example: Between ~23:00 and 00:39 there was a total outage (visible as yellow dashed US Pegel line rise), but the Download graph shows continuous high values.
This is misleading and should be fixed (e.g., by showing gaps or using step lines for actual data points).

Steps to Reproduce

---

What did you expect to happen?

---

What actually happened?

 ___

Deployment Method

Docker Compose

Modem or Router Model

No response

Relevant Logs or Console Errors

Screenshots, Exports, or Extra Context

No response

[itsDNNS]

Thanks — Speedtest results are individual point-in-time measurements, but the connecting line can visually imply continuous throughput between them.

We will change Download and Upload to discrete columns at the actual test timestamps. Missing intervals will remain unmeasured; we will not insert synthetic zero values or use a step line. When Connection Monitor data is available, Correlation will also show a separate reachability lane for observed packet loss/unreachability, with the detailed diagnosis remaining in Connection Monitor.

[Kletternaut]

Hi Dennis,

Thanks for taking this into account.

This doesn't quite belong here, so please bear with me. After years of flawless internet access, I’ve been struggling since June 22, 2026 (at 04:30) with recurring internet outages, as well as massive DNS errors, packet loss, and all sorts of other issues. It is 100% not a router problem; a neighbor in the building is affected too. It could be an issue with the building's distribution box or amplifier, though I consider that unlikely since it does work fine for extended periods. So, what’s going on here? Do you have any idea, or is there a place where this is being discussed?

I'm not getting any response, there

I have a question regarding how to handle and prove total network outages (e.g., complete loss of connection, DNS timeouts, or routing failures).

Here in Germany, the official tool by the Federal Network Agency (Bundesnetzagentur / Breitbandmessung) is a total nightmare in these scenarios. Since the desktop app requires an active internet connection to even initialize or start a test protocol, it completely fails to log a total blackout. If there's no connection, you can't click "start", and for the authorities, the outage basically "never happened."

Since you definitely have the most experience with tracking provider misbehavior, I wanted to ask for your advice:

How do you leverage DOCSight's data in the event of a total outage? (e.g., exporting the modem sync loss logs / packet loss timeline to confront the ISP).

Do you have any practical tips on how to handle the official complaints when the standard "Breitbandmessung" tool is technically unable to log the failure? Have you or other users successfully used DOCSight data as a replacement or backup proof in arbitration procedures (Schlichtungsverfahren)?

Would love to hear your thoughts or how you personally tackle this loophole in the official measurement tools.

Thanks again for your great work!
Tom

[itsDNNS]

Implemented in #744 and #745.

Speedtest results are now rendered as discrete point-in-time measurements rather than a continuous throughput curve. Correlation also includes a separate Connection Monitor reachability lane with ok, degraded, down, and unknown states. Unobserved periods remain explicitly unknown instead of being inferred as healthy or failed.

For outage investigation, the Correlation CSV/PNG exports and Connection Monitor details can help line up reachability, packet loss, modem signals, Speedtests, events, and notes. This can complement modem logs, provider correspondence, and official measurements, but DOCSight does not determine the cause or responsibility for an outage and is not a replacement for official measurement procedures or legal advice.

Thanks for the detailed report and context.

[itsDNNS]

Hi Tom,

I have now had enough time to properly read your longer comment and the Kabeluser thread you linked, and to think about the questions you raised. My previous reply was too focused on the implementation work and did not really address the practical help you were asking for. Sorry about that.

Where I would ask for additional help

For a more detailed discussion with other German cable users, I can recommend:

• ComputerBase
• Vodafone-Kabel-Forum

I have personally had the best experience with the ComputerBase community.

How DOCSight can support this

I want to set realistic expectations: I have not yet received a German success story in which somebody won a court case, conciliation procedure, or provider dispute solely on the basis of DOCSight data.

DOCSight is not an officially certified measurement tool. Its exports do not automatically override the provider's records, and using DOCSight does not guarantee that a regulator, conciliation body, or court will decide in your favor.

At the same time, supporting cases like yours is one of the main reasons DOCSight exists. It is a community project intended to help affected users document recurring cable-network problems and turn many otherwise isolated observations into a coherent timeline, especially when first-level support repeatedly closes tickets or treats each outage as a separate incident.

DOCSight already provides several of the tools needed for that:

• Connection Monitor records reachability, latency, and packet loss, including failed reachability attempts during a complete loss of external connectivity, as long as the DOCSight host itself remains running
• the outage history and raw Connection Monitor samples preserve the underlying observations
• Correlation places reachability, modem signals, Speedtests, events, and notes on the same timeline
• the Journal can be used to record ticket numbers, provider responses, technician visits, and other relevant events
• CSV and PNG exports can preserve and communicate the relevant periods

This does not turn DOCSight data into an official verdict about the cause or responsibility for an outage. It does, however, help build a consistent and understandable evidence package instead of relying on isolated screenshots, memory, or individual Speedtests.

DOCSight data is therefore best used as supporting evidence together with FRITZ!Box logs, provider correspondence, official measurements, and technician reports.

I did have one user in Sweden who used such DOCSight documentation when asserting his rights and was ultimately released from his contract. That is encouraging, but it does not mean the same evidence will automatically be accepted in Germany.

My own experience in Germany

In Germany, the practical escalation route I know is unfortunately still to report the problem through the provider first and then escalate the documented history to the Bundesnetzagentur or its telecommunications conciliation service.

My own first attempt with the Bundesnetzagentur about three years ago was rejected, even though I believed the technical situation was clear and tried to explain it using common sense.

A second attempt a few months later was accepted for processing. By then I had collected substantially more evidence using several separate tools that were later consolidated into DOCSight.

Even with that experience, it is possible that a particular procedure or person handling the case will insist on protocols produced by the official Breitbandmessung application. DOCSight cannot guarantee that its data will be accepted as a substitute.

The limitation you describe for complete outages is real: a measurement tool that cannot initialize without connectivity cannot record the period during which no connection exists. I would therefore document total outages separately and use DOCSight to support the chronology rather than present it as an official replacement for Breitbandmessung.

What I would document in your case

I would maintain one structured evidence package containing:

• every provider ticket number
• when each ticket was opened, closed, and reopened
• the exact start and end of every outage
• whether the connection was completely unavailable or only degraded
• FRITZ!Box logs showing synchronization, DHCP, DNS, and reconnect problems
• DOCSight Connection Monitor reachability and packet-loss data
• Correlation CSV and PNG exports covering the affected periods
• corresponding modem-signal history, events, and incident notes
• all written responses and promised actions from Vodafone
• confirmation that your neighbor was affected at the same time, where possible
• the date, findings, measurements, and reference number of every technician visit
• official Breitbandmessung protocols whenever the connection remains available long enough to complete them

Much of this does not have to be assembled manually from scratch. DOCSight can serve as the central timeline for the technical part of the case. Connection Monitor documents whether configured targets were reachable, Correlation places those observations next to modem levels and other events, and the Journal can connect the technical evidence with ticket numbers, calls, technician appointments, and written responses.

For a complete outage, this is particularly useful because DOCSight can continue recording failed reachability attempts even when an official online measurement cannot be started. Those observations do not replace an official Breitbandmessung protocol, but they can help demonstrate when the outage started, how long it lasted, whether it recurred, and which other modem or network events happened at the same time.

I would continue reporting every recurrence through Vodafone's official support channels. Keep every resulting ticket number and outcome in a chronological log, and submit a written complaint to Vodafone's complaint management as well.

Once enough evidence has accumulated, I would submit the complete and clearly organized history to the Bundesnetzagentur or its telecommunications conciliation service. A coherent timeline is more useful than either isolated screenshots or a large but unstructured collection of ticket numbers.

About the announced technician visit

I saw in your Kabeluser thread that a technician visit has finally been announced. That is the correct first step.

From experience, however, I would be prepared for it not to be the final technician visit.

Before the appointment:

• preserve the relevant FRITZ!Box logs
• export the affected DOCSight periods
• prepare a short timeline of the clearest outages
• have the neighbor's matching experience available, if possible
• note which ticket numbers belong to the same recurring problem

During the appointment, show the technician that the problem also affects another connection in the building. Ask for the measurements and findings to be recorded under a report or ticket reference that you can cite later.

If the connection happens to look normal during the appointment, the historical timeline becomes especially important. Intermittent problems are often difficult to demonstrate from a single measurement taken during a stable period.

My technical impression

The fact that your neighbor is affected at the same time makes a fault limited to your individual router less likely. It does not, however, identify the exact location of the fault.

A common problem could still be located in:

• the building distribution
• the house amplifier
• the handover point
• the return path
• the local cable segment
• another part of Vodafone's network

Longer periods of normal operation do not rule out an intermittent, load-dependent, or temperature-dependent infrastructure problem. The technician's measurements combined with your time-correlated history should help narrow this down.

My main advice is therefore: stay persistent, keep using all official provider channels, and document every step. DOCSight can help you collect, correlate, and export much of the technical evidence, while your ticket history, provider correspondence, official measurements, neighbor confirmation, and technician reports provide the surrounding case.

It should not be presented as a single decisive or officially certified proof. Its strength is that it can turn a recurring problem into a traceable history that is much harder to dismiss as an isolated incident.

I hope this is more useful than my earlier answer. You are welcome to update the thread with the technician's findings, and I will gladly take another look at the resulting evidence.

[Kletternaut]

Wow, thank you so much for taking the time to write such a comprehensive, thoughtful, and incredibly helpful reply! I genuinely appreciate the effort and depth you put into this. Your structured approach and realistic perspective are pure gold for my situation.

You nailed an extremely critical point: during sudden total outages, a FRITZ!Box reboot is often the only way to restore connectivity—which immediately wipes its volatile internal event logs. This leaves affected users with zero evidence on the router side (which, combined with the official Broadband Measurement app’s initialization requirement, leaves a huge gap in official outage tracking!).

This is precisely why DOCSight is so invaluable. Since it records independently, it preserves the exact timeline even when the router reboots.

Two quick thoughts/feature ideas that came to mind:

FRITZ!Box Log Preserver / Syslog Receiver: Since losing logs upon reboot is such a common issue, could DOCSight optionally act as a persistent log collector (e.g. via Syslog or periodic TR-064 event fetches)? Having FRITZ!Box event logs permanently stored and correlated alongside signal levels and reachability directly in DOCSight would be a absolute game-changer.

Crowdsourced Outage Telemetry: As DOCSight grows, an optional opt-in feature where instances report anonymous outage telemetry to a central server could provide undeniable proof of segment-wide issues when ISPs claim "no known outages in your area."

I'm currently preparing everything for the upcoming technician visit using your checklist. I'll also make sure to get a clear report reference from the technician and will update you here once I have news.

Thanks again for building such an amazing tool!

Best,
Tom

[itsDNNS]

Thanks, Tom. I took a closer look at both suggestions.

For the FRITZ!Box log idea, there is a viable technical path. Recent event entries can be retrieved through authenticated FRITZ!Box pull APIs, so DOCSight can potentially collect new entries during its normal polling cycle and preserve them locally before the router log rotates or the box restarts.

I previously evaluated a broader FRITZ!Box event-log integration in #17 and closed it because it was FRITZ!Box-specific, firmware and language dependent, and overlapped with DOCSight's own event detection. Preserving the router's original event timeline is a narrower and more distinct use case, so I have reopened and respecified #17 as an optional FRITZ!Box event archive.

It would not be a generic Syslog receiver. It also could not guarantee capture if the router restarts before the next successful DOCSight poll. Router messages can contain device names, IP addresses, MAC addresses, usernames, or telephone information, so collection must remain explicit opt-in, local by default, filterable, and covered by retention and export safeguards.

The crowdsourced outage idea closely matches #61. That concept was intentionally deferred because it requires a central service, a sufficient local participant base, and a much more demanding privacy and trust model.

Even with explicit opt-in, exact outage times, provider information, approximate location, and the source IP visible to a server can be identifying. Matching reports in the same area would also be supporting evidence, not undeniable proof that the users share the same physical DOCSIS segment.

For now, DOCSight will therefore keep its local-first, no-telemetry model. I would revisit #61 only if the user base and privacy model make a community service genuinely useful and trustworthy.

Please do update the thread after the technician visit. The report reference and findings should be useful context for the timeline you are building.

[itsDNNS]

Thanks again for the suggestion. After a deeper technical evaluation, I have decided not to add FRITZ!Box log archiving to DOCSight and will close #17.

Although retrieval is technically possible, the FRITZ!Box-specific maintenance and privacy cost is disproportionate to the additional value. DOCSight will remain focused on modem-independent signal, reachability, and incident evidence.

For permanent router logs, a dedicated logging solution is the better fit. A Syslog server can be used where the router supports remote Syslog.

[Kletternaut]

Thanks a lot for taking the time to evaluate both concepts so thoroughly! Your reasoning makes absolute sense—keeping DOCSight local-first, privacy-focused, and modem-agnostic is a very solid strategy.

I'm fully focused on the technician visit now and will update this thread as soon as I have news, the service report reference, and new signal data.

Thanks again!

[Kletternaut]

The Vodafone technician was actually here today and replaced both the wall outlet and the modem connection cable. The technician showed me on his tablet (remote diagnostic tool) that my Fritz!Box values are now officially certified by Vodafone as optimal.

He mentioned two interesting technical background details that match what we're seeing:

Outlet filter degradation: Older wall outlets have passive filters (>500 MHz) that degrade over time, heavily dampening the DOCSIS 3.1 OFDM channels. Replacing the outlet fixed the signal issues on my end immediately.

Street cabinet overheating: He confirmed that many outdoor distribution boxes in the neighborhood are purely passively cooled. During hot weather, temperatures inside can easily spike above 80–100°C, causing amplifiers to hit thermal throttling/shutdowns — leading directly to those DNS and connection timeouts in the logs.

Potential DOCSight UI / Threshold Bug
After rebooting the Fritz!Box with the new setup, the Fritz!Box Web UI showed clean values immediately. However, I noticed two discrepancies in DOCSight:

Discrepancy in DS Power Level: DOCSight currently shows -5.6 dBmV for DS Power (OFDM), while the Fritz!Box itself reports 8.1 dBmV.

False "Critical" Status: DOCSight flags DS MER (OFDM) (35.0 dB) as "Critical", even though the range slider/graph below explicitly shows these values right in the middle of the green / good / very good area. (screenshot)

It seems there might be a parsing error for the current value, or a mismatch between the critical threshold check and the green range slider visualization for OFDM channels.

💡 Pro-tip from the Technician for ISP Support
On a side note for anyone struggling to get a technician dispatched (Vodafone closed my ticket 8 times automatically before sending someone out):
The technician gave me a secret workaround: Unplug your router/modem entirely before calling the support hotline. When the automated system/agent runs line diagnostics and gets zero response from your router, the system automatically escalates and dispatches a technician.

Thanks again for your great work on DOCSight — it made tracking and diagnosing all of this so much easier!