Recovery and offline agents
Troubleshoot offline agents and failed rollouts, preserve identity and understand customer versus service-operator recovery duties.
When an agent goes offline
Check the agent service, outbound HTTPS, TLS trust and the service URL. Preserve its identity and state. Reports are queued for replay after connectivity returns; an offline badge alone does not prove the currently served certificate is broken. Use redacted diagnostics to collect local checks, and inspect the actual endpoint separately.
sudo systemctl status clm-agent
sudo journalctl -u clm-agent --since '15 minutes ago'Service logs can contain infrastructure details. Review and redact them before sharing; doctor JSON has a narrower redacted scope.
When a rollout fails
Inspect the certificate’s activity and target results. Recovery depends on the connector and how far the change progressed. An incomplete recovery requires operator inspection; never assume a restored file means the service serves the previous certificate. Verify its served fingerprint.
Make a controlled staging failure part of pilot acceptance. A routine check respects backoff because retrying issuance can create a paid order. Coordinate changes with your service administrator rather than repeatedly retrying a production certificate.
Who restores what
Your infrastructure operator protects agent identities, private-key state, target configuration and local service recovery. The clm.mt service operator owns control-plane backups, master and release-signing keys, isolated restore drills and server upgrades. Customer self-hosted distribution and its full installation/support workflow remain on the later roadmap.
Signed worker updates include startup-health recovery; replacing the stable supervisor is separate maintenance. Contact your pilot operator for account or service recovery. Do not enroll over an existing identity or run a restored agent against real targets until its assignments are confirmed.