Debug a failed AI agent deploy from the timeline, not a war room.
Your deploy just failed and most platforms send you somewhere else to find out why — a separate logs tool, a Grafana dashboard, cluster access you may not have — or they give you nothing but 'deploy failed'. a2a cloud surfaces the actual build and runtime logs right in the deployment timeline: Gitea Actions build logs, the image build, Argo sync status, and pod readiness and crash logs. So you can see exactly which stage broke and why.
per-stage status · live logs · crashloop history · secrets scrubbed
A failed deploy shouldn't send you to a war room.
When an agent deploy breaks, the platform usually hands you a dead end: a generic 'deploy failed', or a link to a separate observability stack you have to context-switch into — assuming you have the access. The logs that would tell you what actually went wrong are scattered across CI, the image build, the GitOps controller, and the pod — and on a crashloop the one log line you need scrolls away when Kubernetes restarts the container. So a small failure becomes a hunt across four tools while your agent is down.
The logs come to the timeline.
a2a proxies the real logs into the deployment view, stage by stage — source, build, runtime, agent card, skills, verify — each with its own status and expandable live logs. Build output from Gitea Actions, the image build, Argo sync status, and pod logs, including the previous container's logs on a crashloop. Secrets are scrubbed before display, and the whole deploy is recorded in a signed receipt.
Build failure (Gitea Actions)
A failed dependency install, a syntax error, a missing lockfile — the build stage goes red and expands to the actual Gitea Actions log. You read the failing step and the traceback inline, in the timeline, instead of hunting for a CI run in a separate tab.
Image build failure
If the container image can't be built — a bad base image, a COPY that misses a file, an OOM during compile — the image stage surfaces the build output directly. You see the exact layer and command that failed, not just 'deploy failed'.
Crashloop / pod not ready
When the pod won't stay up, the runtime stage streams the pod logs — and on a crashloop it also surfaces the previous container's logs, so you see the stack trace from the crash before Kubernetes restarted it. The one line you actually need isn't lost to the restart.
Argo out-of-sync
If the deploy is stuck because Argo hasn't synced — a manifest diff, a pending sync wave, a health check that never goes green — the timeline shows Argo sync status per source. You see it's a reconcile problem, not your code, without opening the Argo UI.
Agent card / skill probe failure
The verify stage runs a live smoke test against the deployed agent. If the agent card won't load or a specific skill fails its probe, the timeline tells you which skill failed and what it returned — so a broken tool doesn't hide behind a green 'running' pod.
Secret / grant issue
Missing env, an unbound secret, a grant the agent needs but wasn't given — these show up as the runtime stage failing on startup, with the pod log explaining what it couldn't reach. Secrets are scrubbed before display, so you get the diagnosis without leaking the value.
Blind deploy vs. log-proxied timeline.
Frequently asked.
Why did my AI agent deploy fail?
Open the deployment timeline and look for the red stage. a2a breaks the deploy into source → build → runtime → agent card → skills → verify, each with its own status. Expand the failing stage and it shows the actual logs — Gitea Actions build output, the image build, Argo sync status, or the pod's runtime log — so you read the real error at the exact stage that broke instead of guessing from a generic 'deploy failed'.
Why is my agent deploy stuck at 'building'?
A deploy stuck at build usually means the Gitea Actions build is still running or has failed without the stage flipping red yet. Expand the build stage to stream the live build log — you'll see whether it's a slow dependency install, a step that's hanging, or a step that errored. If the build itself passed and it's stuck later, check the Argo sync stage: a deploy can sit 'in progress' while Argo waits to reconcile the new image.
How do I see the pod logs for a failed agent deploy?
You don't need kubectl or cluster access. The runtime stage in the deployment timeline proxies the pod logs straight into the dashboard, with secrets scrubbed before display. If the pod is crashlooping, a2a also surfaces the previous container's logs, so the stack trace from the crash is right there even though Kubernetes already restarted the container.
My agent deploys but a skill doesn't work — how do I debug that?
That's what the verify stage is for. After the pod is running, a2a runs a live smoke test against the deployed agent and its skills. If the agent card fails to load or a specific skill fails its probe, the timeline names the failing skill and shows what it returned — so a broken tool doesn't hide behind a green, 'running' pod. You debug the specific skill, not the whole deploy.
Do I need Grafana or cluster access to debug a deploy on a2a?
No. The whole point of the log-proxied timeline is that you debug a failed deploy from the deployment view, not a war room. Build logs, image build output, Argo sync status, and pod runtime logs — including previous-container logs on a crashloop — are surfaced in the dashboard with secrets redacted. No kubectl, no Grafana, no cluster credentials required.
Related guides.
All guides live in the guides index.
Trust the receipt.
a2a cloud deploys any agent — LangGraph, OpenAI Agents SDK, CrewAI, or custom — and streams the real build and runtime logs into a per-stage deployment timeline. Gitea Actions build, image build, Argo sync, pod readiness and crashloop history, and a live smoke test that names the failing skill — secrets scrubbed, no cluster or Grafana access needed, and every deploy recorded in an Ed25519-signed receipt. See which stage failed and why, from one screen.