Freeze one card and one disputed fact
Record the PBX node, FreePBX and Dashboard versions, module signature and enabled state, card and metric, selected interval, browser time, displayed timestamp, expected value, actual value and the independent observation that conflicts. Preserve the page response and error before refreshing, applying configuration, dismissing notices or restarting anything.
Classify the first symptom as missing card, hook failure, collector disabled, collector error, stale cache, stale history, unit mismatch, wrong node, wrong interval, transformed aggregate or genuine runtime change. A blank card is not automatically a stopped service, and a green card is not proof that calls or media work.
Verify the installed dashboard and contributing module
Use normal Module Admin evidence to confirm the installed Dashboard package, signature, status and supported update channel. Identify whether the disputed card is built in or supplied by another module such as System Admin or Firewall. The release/17.0 metadata reviewed here lists version 17.0.5 and a security-related change, but that does not establish the state of the selected PBX.
Update only through the supported change process with backup, impact review and rollback. Do not copy repository files, force a module operation or expose administrator access to make a card render.
Follow collector, cache, clock and history before service state
For system graphs, verify whether persistent collection is enabled, the configured expiry, scheduled collector, latest cached timestamp, stored interval and host clock. Check the same node and unit. The reviewed source enforces a minimum 50-second expiry and runs scheduled collection each minute when enabled; locally installed behavior and stored history remain authoritative.
If the newest sample is old, repair the earliest demonstrated collector, dependency, storage or permission boundary. Do not generate load, fill a disk, restart Asterisk or repeatedly poll an expensive provider merely to force a graph to move.
Compare the exact owner through a read-only surface
Use the narrow supported source for the disputed value: Asterisk CLI or Asterisk Info for current telephony objects, operating-system or service-manager evidence for processes and resources, the documented Dashboard GraphQL disk query for its response, and CDR or CEL for historical call records. Capture both observations inside one bounded window.
Keep configured trunks, outbound registrations, contacts, channels, bridges and calls separate. Keep process running, listener reachable, login accepted and business function successful separate. If the source and card disagree, inspect hook, query, cache, transformation and timestamp before modifying the working object.
Repair the first proven boundary and retest outcomes separately
Correct only the demonstrated module, hook, collector, dependency, cache, clock, unit or rendering fault. Preserve before-and-after card and source evidence. If a service restart is actually required, check active calls and dependent jobs, schedule the interruption and keep rollback explicit.
Then test the business function independently. A current dashboard is not proof of registration, routing, queue answer, recording, voicemail, GraphQL authorization or two-way media, while a successful call does not prove resource history or every notification is current. No PBX, dashboard, collector, process, filesystem, endpoint, trunk, channel, packet, media stream or live call was inspected or tested.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Sangoma FreePBX System Status ↗
- Sangoma FreePBX Reports modules ↗
- FreePBX System Dashboard release/17.0 source ↗
- FreePBX System Dashboard release/17.0 module metadata ↗
- FreePBX System Dashboard release/17.0 module class ↗
- Sangoma Dashboard module GraphQL API ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.