where logs live
blind deploy
A separate observability tool — if you have access — or nothing at all.
a2a timeline
In the deployment timeline, per stage, expandable the moment it goes red.
logs in the timeline
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 · bounded logs · crashloop history · secrets scrubbed
0
stages surfaced
0
cluster access needed
scrubbed log tail per source
the problem
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.
'Deploy failed' with no stage attribution — you reverse-engineer where it broke.
Build, image, sync, and pod logs live in four different tools.
Crashloop restarts scroll the crash trace out of view before you read it.
Reading pod logs at all often requires kubectl or Grafana access you don't have.
the a2a way
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 logs. Build output from Gitea Actions, Argo sync state, and pod logs, including previous-container output on a crashloop, are bounded and scrubbed before display. The deployment record keeps commit, image, events, logs, and verification together; it is not an ExecutionReceipt.
Build failure (Gitea Actions)Image build failureCrashloop / pod not readyArgo out-of-syncAgent card / skill probe failureSecret / grant issue
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 log view fetches a bounded, scrubbed pod-log tail — and on a crashloop it also surfaces the previous container's output, so the stack trace from before Kubernetes restarted it remains available in the deployment record.
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 fetches the live Agent Card and checks that it exposes a valid skill surface. If the card won't load or contains no callable skills, the timeline identifies that discovery failure instead of hiding it behind a green 'running' pod. Exercising a skill's behavior requires a separate invocation-based smoke test.
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.
side-by-side
Blind deploy vs. log-proxied timeline.
which stage failed
blind deploy
'Deploy failed.' You reverse-engineer where in the pipeline it broke.
a2a timeline
source → build → runtime → agent card → skills → verify, each with its own status.
crashloop logs
blind deploy
The pod restarts and the crash log scrolls away before you can read it.
a2a timeline
Previous-container logs are surfaced automatically on a crashloop.
access needed
blind deploy
kubectl, Grafana, or Argo access — plus permission to reach the cluster.
a2a timeline
None. The logs are proxied into the dashboard, secrets scrubbed.
proof of what ran
blind deploy
You trust the console said 'success' at some point.
a2a timeline
Commit, image, stages, logs, and verification live on the deployment record; signed receipts belong to invocations.
dimension
blind deploy
a2a timeline
where logs live
A separate observability tool — if you have access — or nothing at all.
In the deployment timeline, per stage, expandable the moment it goes red.
which stage failed
'Deploy failed.' You reverse-engineer where in the pipeline it broke.
source → build → runtime → agent card → skills → verify, each with its own status.
crashloop logs
The pod restarts and the crash log scrolls away before you can read it.
Previous-container logs are surfaced automatically on a crashloop.
access needed
kubectl, Grafana, or Argo access — plus permission to reach the cluster.
None. The logs are proxied into the dashboard, secrets scrubbed.
proof of what ran
You trust the console said 'success' at some point.
Commit, image, stages, logs, and verification live on the deployment record; signed receipts belong to invocations.
questions
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 the expected image has not reconciled yet. Open the build log view to fetch the latest bounded Actions tail and see whether a dependency step is slow, hanging, or failed. If the build passed and progress is stuck later, inspect the Argo and runtime stages to see whether the expected image and Knative service have converged.
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?
Start with the verify stage: after the runtime is ready, a2a fetches the live Agent Card and checks that it advertises a valid skill surface. That catches discovery and packaging failures, but it does not execute each skill. To debug behavior, invoke the affected skill with a bounded smoke input. That real invocation is separate from the deployment record and can emit a signed ExecutionReceipt for the run.
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.
keep reading
Related guides.
All guides live in the guides index.
debug from the timeline
Trust the receipt.
a2a cloud deploys managed agents with the real build and runtime evidence in a per-stage deployment timeline: Gitea Actions output, expected image and source revision, Argo sync, pod readiness and crashloop history, live Agent Card, and advertised skills — bounded and secrets scrubbed, with no cluster or Grafana access needed. The deployment record tells you what release failed and where; a separate skill invocation can emit a signed ExecutionReceipt when you need run-level evidence.