Use Maintenance and Activity to identify the operation that failed before changing keys, deleting zones or running a recovery. Provider health, public DNS and website availability are different checks.

Inspect the original result

1. Open PowerDNS → Zones and identify the intended provider and zone.
2. Review its records, owner, secondary status and lock where relevant.
3. Open Maintenance and inspect the relevant task’s last result and time.
4. Review Activity for the exact action and redacted upstream response.
5. Confirm the normal Blesta cron is running for scheduled work.

The zone-health probe checks the provider’s zone and reported nameservers. It is not a website, mail-delivery or certificate test. Verify delegation and authoritative DNS separately when visitors receive unexpected answers.

Separate the likely causes

A timeout can indicate network access; a refused key is an authentication issue. A successful server connection test does not prove every record write or signing action. For read-only records, check whether the zone is a transferred secondary before changing staff permissions.

For a failed restore, inspect the actual current state and saved safety snapshot. Recovery can stop part-way; do not assume a red error means nothing changed. For scheduled backups, confirm an actual saved snapshot rather than only a configured schedule.

Review destructive actions

Check orphan-cleanup and provider-deletion settings before acting on zones linked to cancelled or terminated services. Explicit Delete zone removes the provider zone and records; removing a client relationship is different.

Retain the original action time, intended result and exact redacted error while your hosting team checks the failing stage. Use supported module/admin controls and your server administrator’s authorised process; do not repair module data or server settings with guessed commands.

Check scheduled tasks and zone state

Your hosting team and PowerDNS administrator should compare the original operation, current zone/record/key state, Activity and task result to identify connection, authentication, API operation, signing or scheduling failure. Review actual authoritative DNS separately from module health and billing status. After a partial restore or uncertain key operation, inspect what exists and the available recovery scope before another action.

See the PD PowerDNS Blesta guide for related tasks, or explore PD PowerDNS.