VoIP.infoThe independent guide to business communications.
VoIP.info Guide

FreePBX System Dashboard: interpret cards, counters and history as bounded evidence

Read FreePBX dashboard modules without collapsing cached statistics, hook-provided cards, runtime objects, notifications and call outcomes into one health verdict.

Reviewed 2026-10-16Sangoma FreePBX System Status, Reports and Dashboard GraphQL documentation plus the FreePBX System Dashboard release/17.0 repository were reviewed October 16, 2026. The public System Status page spans older 2.10/2.11 and FreePBX 12+ interface generations, while the reviewed release/17.0 metadata exposed System Dashboard 17.0.5 and a security-related changelog entry; neither source establishes the installed version, enabled collectors, refresh time, hook providers, stored history or current state on a selected PBX. Dashboard cards, cached and persistent statistics, GraphQL responses, runtime objects and service outcomes remain separate. No PBX, module, dashboard, collector, GraphQL request, process, filesystem, endpoint, trunk, channel, packet, media stream or live call was inspected or testedAdvancedDocumentation based · not lab tested

Identify the dashboard implementation and observation window

Sangoma documents System Status as a Reports surface for active calls and trunks, CPU, memory, disks, network, selected services and uptime. The same page spans older 2.10/2.11 and FreePBX 12+ interface generations, so its labels and screenshots are conceptual evidence rather than an exact map of every FreePBX 17 build. Record the PBX node, FreePBX and Dashboard module versions, signature and enabled state, browser time, selected graph interval and last refresh before interpreting a card.

The reviewed release/17.0 metadata identified System Dashboard 17.0.5, standard-repository placement, FreePBX 17 support and a security-related changelog entry. Repository state does not prove that version is installed or that an uninspected host is affected or repaired. Compare the installed signed package with the current supported channel through normal Module Admin controls.

Treat every card as a separate provider and evidence contract

The release/17.0 module class exposes built-in hooks for overview, notifications, system statistics, Asterisk statistics, uptime and other sections, and can accept dashboard sections from other modules. Disk content can also come from System Admin when its dashboard method is available. A page that renders successfully therefore does not prove that every card used the same source, refresh path or timestamp.

Record the card name, contributing module, query or collector, timestamp, node and transformation. A blank disk panel can be a provider or permission failure while call counters still render. A firewall warning can be intentionally suppressed by a dashboard setting without changing firewall state. Do not turn one green card into a system-wide health statement.

Keep call, trunk and channel aggregates distinct

A dashboard count is an aggregate selected by its implementation. Preserve the exact label and compare it with the owning Asterisk objects at the same time. One call can involve multiple channels, a trunk can be configured without being registered or usable, and registration does not prove number routing, authorization, answer or media.

Use Asterisk Info, the installed CLI, CDR or CEL, queue evidence and signaling only for the question they own. A zero counter does not prove there were no historical calls, and a nonzero counter does not identify a caller, destination, bridge or media result. Capacity and quality require separate measurements.

Read refresh, cache and persistent history before comparing graphs

The FreePBX 17 source defines a minimum system-statistics expiry of 50 seconds, uses cached latest system information and schedules collection work each minute when collection is enabled. It also defines a setting that can disable persistent CPU, memory and channel-statistic collection and keeps a bounded history in the reviewed implementation. These are source behaviors to verify locally, not universal guarantees for every installed revision.

Compare browser refresh time, cache timestamp, collector run, host clock, graph interval and raw source interval. Network units on the older System Status page are KiloBYTES rather than Kilobits. Never compare unlike units or a minute sample with a daily aggregate and call the difference a fault.

Separate notifications and process labels from service acceptance

Dashboard overview and notification cards can summarize module-supplied notices, process state and service warnings. A notice can be dismissed, reset, suppressed or stale without repairing or breaking its underlying condition. Likewise, an Asterisk, web, database or SSH process label does not establish correct configuration, safe exposure, successful authentication or user-visible service.

Preserve the raw notice identity and owning module, then verify the underlying filesystem, process, listener, database, module, queue or route through its supported surface. Do not delete a notice, restart a service or broaden a network listener merely to make the dashboard appear healthy.

Accept dashboard evidence and PBX service independently

A bounded acceptance test records an idle baseline, one approved workload, the exact dashboard changes and the owning runtime evidence in the same window. For disk questions, the documented Dashboard GraphQL query can return storage path, available, used, total and percentage values, but an API response is not proof of filesystem write success, alert delivery or future capacity.

Retest the dashboard provider after any supported module or collector repair, then test the required PBX function separately: registration, routing, queue behavior, recording, voicemail, two-way media or administrative access. No dashboard, alert, process, resource, GraphQL, call or media result is claimed from this documentation review.

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.

Continue your research

Hub

FreePBX

Plan and administer a FreePBX 17 system on Debian 12 using the supported project installation path.

Explore topic →
Guide · Sangoma Asterisk Info documentation, the FreePBX Asterisk Info and ARI Manager release/17.0 repositories, and current Asterisk CLI documentation reviewed October 16, 2026. The Asterisk Info release branch exposed module version 17.0.2 and an ARI Manager dependency when reviewed; that repository state does not establish the versions installed or loaded on a selected PBX. The report surfaces snapshots from Asterisk, while configuration ownership, module state, report implementation, time, node, command output and service outcomes remain separate. No PBX, module, ARI or AMI session, endpoint, trunk, channel, queue, conference, voicemail box, subscription, packet, media stream or live call was inspected or tested

FreePBX Asterisk Info: read each report as a bounded runtime snapshot

Use FreePBX Asterisk Info without collapsing module availability, generated configuration, loaded Asterisk state, report rendering and call outcomes into one status label.

Read guide →
Guide · FreePBX 17 / Debian 12; module UI varies

FreePBX module administration and updates

Inventory module state, preview dependencies and signatures, change the smallest intended set, and prove reload and call behavior before closing the window.

Read guide →
Guide · FreePBX CDR Reports and CDR user guidance plus current Asterisk CDR specification and Asterisk 22 CDR and CEL references reviewed October 11, 2026; installed module, schema, backends, report roles, timezone, retention and call behavior require system-specific evidence, and no FreePBX host, report, call, channel, CDR, CEL event, log, database, export, billing rule, backup or retention workflow was inspected or tested

FreePBX CDR Reports: query, record lifecycle and evidence boundaries

Use FreePBX CDR Reports without turning one filtered row into a complete conversation, billing record or channel-event history.

Read guide →
Guide · FreePBX Asterisk Logfiles release/17.0 repository and security advisory, Sangoma module indexes and retention note, and current Asterisk logging documentation reviewed October 12, 2026; repository and advisory state do not prove the installed module version or patch state, the Sangoma retention note describes an older FreePBX Distro path rather than the FreePBX 17 Debian 12 baseline, and no PBX, module, file, logger channel, disk, rotation job, call or captured event was inspected or tested

FreePBX Asterisk Logfile Settings: generated channels, runtime and retention

Separate the installed Logfiles module, saved rows, generated logger configuration, loaded Asterisk channels, actual writes, rotation owner and retained evidence.

Read guide →
Guide · Current Asterisk 23 res_prometheus configuration, sample configuration, implementation, built-in HTTP-server guidance and official release history plus the Prometheus pull-model overview reviewed October 15, 2026; Asterisk documents res_prometheus from 17.0.0, while channel- and bridge-detail cardinality controls are version-specific and the installed branch, package, module providers, HTTP prefix, URI, authentication, network policy, scraper, label set, retention and alert rules remain deployment specific; no host, module, configuration, credential, HTTP route, scrape target, metric series, dashboard, alert, endpoint, registration, channel, bridge or live call was inspected or tested

Asterisk Prometheus metrics: module, HTTP route and cardinality boundaries

Expose a bounded, authenticated Asterisk metrics route, prove the installed metric providers and keep scrape success separate from call-service health.

Read guide →
Troubleshooting · Sangoma FreePBX System Status, Reports and Dashboard GraphQL documentation plus the FreePBX System Dashboard release/17.0 repository were reviewed October 16, 2026. The public System Status page spans older 2.10/2.11 and FreePBX 12+ interface generations, while the reviewed release/17.0 metadata exposed System Dashboard 17.0.5 and a security-related changelog entry; neither source establishes the installed version, enabled collectors, refresh time, hook providers, stored history or current state on a selected PBX. Dashboard cards, cached and persistent statistics, GraphQL responses, runtime objects and service outcomes remain separate. No PBX, module, dashboard, collector, GraphQL request, process, filesystem, endpoint, trunk, channel, packet, media stream or live call was inspected or tested

FreePBX dashboard is stale, empty or contradicts runtime evidence

Trace one dashboard discrepancy through module version, card provider, collector, cache, timestamp, unit and owning runtime object before restarting services or changing a working call path.

Read guide →