Build WordPress Health Checks with Limited Access

A central WordPress dashboard can check integrations without receiving every site’s API secrets or customer records. Each feature plugin can perform its own health check and return a small, safe result. In a monitoring plugin for a group of sites, I used WordPress Application Passwords for authentication and a dedicated capability to authorize checks. The dashboard received status and diagnostic information rather than raw provider responses. This approach keeps integration logic on the site that owns it and gives support staff a consistent way to identify whether a failure involves access, configuration, or an upstream service.

Keep the check beside the integration

A verification plugin understands its own upstream API, configuration, and failure modes better than a generic dashboard ever will. I kept the actual check beside the feature and made the monitor an orchestrator: identify the site, authenticate, request a check, normalize the result, and display it.

This prevents the central plugin from duplicating business logic or needing every remote secret. It also lets a feature plugin version its endpoint when its internal response format changes.

Authorize checks separately from sign-in

An Application Password proves which WordPress user made the request. It does not automatically mean that user should run monitoring operations. I added a dedicated capability and required it on the remote REST route.

Administrators can receive that capability, but the better operating model is a dedicated low-privilege monitor user. One account per website is sufficient; the capability covers supported feature checks without creating a separate secret for every plugin.

Keep the health response small. I normalized status, a safe summary, version information, timing, and bounded diagnostic details. I explicitly excluded protected health information, form entries, verification response bodies, OAuth tokens, and remote plugin secrets.

A monitoring response should help an operator decide what to inspect next. It does not need to become a remote debug dump. Detailed logs can remain on the system that owns them, under its existing access controls.

Manual checks came before automation. The initial release is view-and-test only. I did not add cron checks, notifications, history, charts, or automatic repair. Manual execution let me validate authentication, error mapping, timeouts, and operator language before creating another background system.

This restraint matters. If the checks do not yet give dependable results, alerts will generate avoidable support work. Automatic repair also needs its own access controls and recovery plan.

Test rejected requests and safe responses

1. Reject unauthenticated requests.
2. Reject authenticated users without the monitor capability.
3. Require HTTPS for configured remote sites.
4. Never return saved passwords through admin or REST responses.
5. Normalize remote timeouts and malformed responses.
6. Keep privileged local changes behind both capability and nonce checks.
7. Verify a valid check cannot expose protected payloads.

These tests describe the feature more accurately than a screenshot of a green status badge.

Return enough detail for the next support step

Teams need to know whether critical integrations can respond, but they do not need to centralize every secret and record to get that answer. A limited response reduces what a compromised monitor could expose and keeps the feature plugin responsible for its own checks.

It also gives support a consistent first step. They can distinguish authentication failure, unavailable endpoint, invalid configuration, and upstream service trouble before escalating to a developer.

Error language became part of the API. A raw exception might reveal a URL, response body, or configuration detail and still fail to tell an operator what to do. I mapped failures into a small vocabulary: authentication rejected, capability denied, endpoint unavailable, check misconfigured, upstream timed out, and response invalid. Each status includes a safe next action without pretending to diagnose beyond the evidence.

This also improved compatibility. The dashboard consumes the documented response format rather than matching whatever message a remote HTTP library happens to produce. A feature plugin can change its internal client without changing the monitor’s meaning. For developers, bounded diagnostic codes remain available for logs and tests. For administrators, the interface answers the immediate question: is this a credential problem, a site problem, or a provider problem, and who owns the next step? Clear failure categories reduce both secret exposure and support time.

Configuration storage received the same attention. Passwords are accepted through a write-only interface, encrypted or protected according to the installation’s available mechanism, and never returned as form defaults or REST fields. A replacement secret can be saved without proving the old value to the browser. Backup and support procedures must acknowledge that credential separately from ordinary display settings.

Release artifacts are verified separately from source. I record the expected checksum and version, install through the normal plugin path, and confirm the remote route still enforces the capability. Monitoring code deserves the same supply-chain discipline as the features it observes.

Add scheduling after manual checks are reliable

Begin with one manual check and a dedicated account that has only the required access. Test unauthenticated requests, insufficient permissions, invalid responses, and timeouts as carefully as the successful case. Review the response for secrets and unnecessary personal information. Once operators can distinguish the failure types and know who should act, consider scheduling and alerts. Their timing and recipients should follow the support workflow, including how repeated failures and unavailable monitoring are handled.

Photo by Tima Miroshnichenko on Pexels.