Observe
Track service state, node health, capacity and application-level signals before troubleshooting begins.
PLATFORM / OPERATIONS
Infrastructure and Operations all in one plane.
Monitoring, updates, recovery, service management and engineering ownership turn a technical stack into a dependable service. Webcore treats those activities as part of the platform, not as work left for the customer after deployment.
OBSERVEHealth · capacity · logsACTRecover · update · repairIMPROVEReview · tune · standardiseOperations is a continuous loop.
MonitoringDiagnosticsRecoveryUpdatesBackupsEngineering
OPERATING MODEL
Do not wait for a customer report to discover the platform is unhealthy.
Operational visibility should expose the signals that matter, and the platform should provide a path from observation to action. Webcore brings infrastructure state, service controls, application diagnostics and recovery workflows into the same operating model.
Recover
Provide controlled restart, automatic recovery and restore workflows where they are appropriate.
Maintain
Keep runtimes and platform releases visible and manageable across the fleet rather than updating hosts ad hoc.
SERVICE MANAGEMENT
Know what is running and what needs attention.
On WordPress hosting nodes, the control plane can see the state of Nginx, Apache, MariaDB, the Webcore Agent and installed PHP-FPM runtimes. Supported services can be restarted from the Panel, while selected components can use automatic-recovery policies with defined retry windows and cooldown behaviour.
Make active, inactive and degraded conditions visible to operators.
Recover supported components deliberately instead of relying on undocumented server-side fixes.
Set retry and cooldown behaviour so automatic recovery remains bounded and observable.
UPDATES
Fleet maintenance should be a managed workflow.
Platform and node releases need an operational view: what is installed, what is current and where an update needs to happen. Webcore keeps update activity within the control-plane model rather than treating every server as a separate maintenance project.
See installed and target platform releases across hosting nodes.
Routine node updates use node-specific read-only deployment credentials rather than distributing a shared unrestricted key.
Keep infrastructure lifecycle decisions separate from the application workloads already running on a node.
BACKUP & RECOVERY
Recovery belongs in normal operations.
A backup is only useful if the path back to a working application is understood. In the WordPress Platform, scheduled and on-demand backups, restore controls and staging safety snapshots sit alongside the site they protect.
Scheduled and on-demand workflows keep files and databases within the platform operating model.
Restore and validation should be operational workflows, not an emergency procedure discovered during an incident.
ENGINEERING
Some incidents do not respect product boundaries.
A slow or unavailable application may cross DNS, TLS, the web tier, PHP, database, storage or WordPress itself. Webcore's operating model is designed so those layers can be investigated as one system rather than bounced between unrelated support queues.
Use site-level logs, runtime settings and WordPress diagnostics alongside infrastructure signals.
Correlate service health and capacity with what the application is doing.
Keep responsibility explicit so customers know which layer Webcore is expected to operate.
OPERATIONS
Make the platform someone’s responsibility.
Tell us where your current operational burden sits — monitoring, maintenance, recovery, performance or the whole platform beneath the application.
Talk to an Engineer