01 / THE ROLE
In this lab.
Speedtest Tracker appears in the documented service inventory with a PostgreSQL dependency. The current read-only check did not show a running Speedtest container on its documented host, so this page records the intended role and outstanding reconciliation rather than claiming it is an accepted running service.
02 / THE CONNECTIONS
Follow the flow.
- STEP 01Scheduled measurement
- STEP 02Connection test
- STEP 03Stored result
- STEP 04Trend view
03 / How it works
How it works.
The application schedules or runs measurements and stores the resulting history. Interpreting a test requires context: test destination, local activity and the path being measured. This site does not publish the connection identity, provider details or private measurement history.
04 / Persistent data & recovery
Persistent data & recovery.
Configuration and database history are the main assets to classify. Decide whether historical results are worth retaining or whether a fresh measurement history is acceptable after recovery. The database service’s recovery is a separate dependency.
05 / How to check it
How to check it.
The earlier documented audit found that the intended web URL served a different application. The current running-container check did not establish a Speedtest deployment. Reconcile the intended deployment and endpoint before enabling a health claim or interpreting any returned HTTP success as Speedtest health.
06 / Decisions & limits
Decisions & limits.
This is an example of why probes need an application identity check. A service being installed, a container running and the intended user interface functioning are three different statements.