Understanding the Dashboard
Practical PanelConfig guidance for Understanding The Dashboard, with safe workflow, clear records, and operational review notes.
Understanding The Dashboard explains how this part of PanelConfig should be used in a production hosting operation. It focuses on practical decisions, audit visibility, and safe execution rather than marketing language. Jobs decouple panel actions from server-side execution; use the queue and audit trail to understand what happened.
Usage
Use this guide when you are configuring, reviewing, or troubleshooting understanding the dashboard for a hosting provider, agency, reseller, or customer account. It is useful during initial setup, operational handover, incident review, and routine maintenance.
Workflow
- Open the related PanelConfig page: Public website, /docs, /app/auth/login.php, PCAdmin Dashboard, PCUser Dashboard.
- Confirm the account, domain, user, or server context before changing anything. In provider environments, many records have similar names.
- Review current status, ownership, package limits, and any pending jobs before making a change.
- Make the smallest safe change first. For destructive or customer-visible operations, keep a ticket or internal note with the reason.
- Re-check the page, job queue, audit log, and any affected service status after the operation completes.
Checklist
| Check | Why it matters |
|---|---|
| Ownership | Prevents changes on the wrong customer, reseller, or hosting account. |
| Current status | Avoids repeating an action that is already pending, suspended, queued, failed, or completed. |
| Limits and dependencies | Shows whether package limits, DNS state, storage, service health, or credentials affect the result. |
| Audit trail | Gives support and operations teams a reliable record of who changed what and why. |
Related
PCAdmin: Public website, /docs, /app/auth/login.php, PCAdmin Dashboard, PCUser Dashboard
PCUser: PCUser Dashboard, Profile, Domains, Websites, Email, Databases, SSL, Backups
Related PCCLI: php cli/pc health
Records
Typical records involved: users, roles, permissions, hosting_accounts, settings, audit_logs, login_history. Some actions only read these records, while write actions may update status fields, create queue records, write audit entries, or refresh timestamps. For integration-ready areas, do not assume an external provider action has completed until the local job and provider-side evidence agree.
Notes
Security and audit notes: use least-privilege access, avoid sharing raw credentials, keep customer-impacting changes tied to a reason, and review Audit Logs or Login History when an action affects authentication, access, DNS, mail flow, backups, SSL, firewall, WAF, or account status.
Troubleshooting
- If the page is empty, confirm the related database table exists and that the user role has permission to view the module.
- If a change appears stuck, check Jobs, Job Logs, and Services before repeating the operation.
- If an external dependency is involved, verify it independently: DNS propagation, ACME challenge visibility, remote backup storage, mail DNS records, or provider API state.
- If the result is sensitive or customer-visible, capture the exact timestamp, account id, domain, and operator before escalating.
Example
php cli/pc healthRelated
php cli/pc jobs:list, php cli/pc jobs:run-next