System status

Status visibility for API, connector polling, workers, and storage.

Review the customer-facing components used for dashboard access, connector synchronization, repair processing, and backup operations.

API

Health

Connector

Polling

Worker

Queues

Storage

Backups

wpfixagent.com/status

Incident communication model

DetectMonitor API, worker, Redis, database, and storage availability.
CommunicatePublish customer-facing updates for service-impacting incidents.
ResolveRecord what changed and when service recovered.
ReviewAdd post-incident notes for major events.
Operational

API health

The backend exposes a /healthz endpoint for basic service checks.

Planned

Connector polling

WordPress sites depend on outbound polling and WP-Cron behavior.

Planned

Repair processing

Command status, retries, leases, verification, and rollback outcomes remain visible per website.

Planned

Backup storage

Lower plans can retain protected local restore archives. Off-site storage is required for protection against host or disk loss.

Incident communication model

1

Step 1

Detect

Monitor API, worker, Redis, database, and storage availability.

2

Step 2

Communicate

Publish customer-facing updates for service-impacting incidents.

3

Step 3

Resolve

Record what changed and when service recovered.

4

Step 4

Review

Add post-incident notes for major events.

FAQ

Common questions

Does this page guarantee live availability?

No. Dashboard health and connected-site status provide operational signals; service-impacting questions should be sent to support.

What does connector polling depend on?

The WordPress connector depends on outbound API access and scheduled WordPress cron execution.

Where is API health?

The backend health endpoint is /healthz.

Free 14-day trial · no card required

Give every WordPress site a safer path from incident to verified recovery.

Install the connector, pair with a one-time token, and start monitoring in minutes -- upgrade whenever you're ready.

Start Free Trial