Use Maintenance and Activity to identify the failed operation before changing credentials or recreating zones. A provider-health status is separate from public DNS resolution and website availability.

Check the original result

1. Open Google Cloud DNS → Zones and identify the provider/project and DNS suffix.
2. Review ownership, available records, status and most recent snapshot.
3. Open Maintenance and inspect the relevant last task result/time.
4. Review Activity for the action and redacted provider response.
5. Confirm the normal Blesta cron for scheduled work.

The released health probe asks the provider for the zone and its reported nameservers. It is not a website, mailbox or certificate test. Check public authority and records separately when visitors see the wrong result.

Separate identity and access failures

A successful connection test lists managed zones; it does not prove every zone operation. Check the project ID, service-account identity, API enablement and exact refused action. A zone that lists but fails to open needs the managed-zone identity checks, rather than blind recreation.

A malformed key, missing DNS permissions and a disabled API need different corrections. Do not repeatedly rotate a working key to fix a resource or policy problem.

Review orphan and deletion choices

An orphan is linked to a cancelled, terminated or removed domain/service. Check saved cleanup and provider-deletion settings before acting on it. Removing a binding is different from an explicit Delete zone request.

Treat Delete zone as destructive. The current driver removes ordinary record sets before requesting removal of the managed zone; a nonempty zone is not protected from deletion merely because it contains records. A later failure can leave some records already removed. The module attempts a pre-delete snapshot, but deletion is not conditional on that snapshot succeeding. Verify a usable backup and the intended identity before any planned deletion; never use deletion to diagnose a warning.

Use the relevant maintenance action deliberately and inspect its result. Reconcile any uncertain write before repeating it. Keep task time and redacted details for support; never include service-account JSON, tokens or unrelated customer data.

Check the maintenance result

Your hosting team and Google Cloud administrator should compare the last job time/result, normal platform cron, saved service-account identity and tracked zone with the actual provider resource. Check authoritative DNS and application availability separately. For an orphan warning, establish whether the linked domain/service ended and review cleanup and provider-deletion choices before acting. Do not use Delete zone as a refresh or diagnosis action.

See the PD Google Cloud DNS Blesta guide for related tasks, or explore the module.