Diagnose common connection and deployment issues.
Start with the resource's most recent operation and exact failure output. ServerChirp keeps expected failures attached to the step that produced them, which is more useful than retrying from the top without changing the underlying condition.
Do not open an inbound agent port. The agent is designed to connect outward.
Check the failed stage for an unsupported Ubuntu version, package-manager lock, unreachable repository, conflicting preinstalled service, or insufficient memory or disk. Use the guided retry so ServerChirp can reconcile completed steps.
Open the deployment and identify whether the failure occurred during source fetch, dependencies, build, a hook, runtime start, or health check.
Verify public DNS from more than one resolver, confirm that ports 80 and 443 reach the server, and check that a CDN proxy is not preventing HTTP-01 validation. Use Let's Encrypt staging while testing repeated configuration changes.
Check source permissions, free temporary disk, destination credentials, bucket or remote path permissions, and network reachability. A destination can accept a small connectivity check while rejecting a multipart upload, so keep the full operation output.
Include the resource ID, operation ID, approximate time and timezone, expected result, and the failed step's output. Never include an agent token, bootstrap command, private key, API token, database password, or webhook secret.
