Skip to main content
Clicking a microservice in the list opens its detail page. The header carries the live status badge and status detail, Deploy / Redeploy and Save inline, and Restart and Undeploy in the overflow menu.

​
The rollout strip

When a deploy is in flight, a staged progress strip shows where it has got to:
1

​
Applying manifests

The Kubernetes objects have been submitted. No pods exist yet.
2

​
Scheduling pods

Pods are being created, scheduled onto nodes, and pulling their image. This is where an unpullable image shows up.
3

​
Ready

Some replicas are up and passing readiness. This step appears once partial readiness is detectable.
4

​
Active

The rollout is complete and the service is ready.
If the rollout fails, the strip stops at the stage that failed and shows the error detail alongside it. The deploy button re-labels itself to match the state — Deploy before a first rollout, Redeploy once active, Retry deploy after a failure. Status is polled roughly every three seconds while a deploy is in progress, and polling stops once the deploy settles, so a page left open on a healthy service isn’t generating traffic indefinitely.

​
Configuration tab

The microservice’s XanoScript, in the same Monaco editor used elsewhere in Xano. It tracks dirty state, so Save is only live when there is something to save, and navigating away with unsaved changes prompts you first. Saving stores the definition. It does not deploy — use Deploy / Redeploy to roll the change out.

​
Logs tab

Container logs, tailed.
  • Container picker — for a multi-container pod, choose which container’s logs to read.
  • Previous container — toggle to read the logs of the previous, crashed instance of a container. This is how you see why something crash-looped, since the current container’s logs start after the restart.
  • Refresh — pull the latest output on demand.
  • Auto-refresh — poll every few seconds while the tab is open.
If there’s nothing to show — the service has never run, or the container has produced no output — the tab says so rather than showing an empty box.
Logs are the right tab for an application that started but is misbehaving. For a container that never started, go to Pods — the reason will be in the pod status, not in logs that were never written.

​
Pods tab

A table of the pods backing the deployment: The table auto-refreshes while the tab is open, and rows are clickable.

​
Pod detail

Clicking a row opens a draggable slide-in panel with the full pod detail:
  • Metadata — name, node, phase, start time
  • Labels and annotations
  • Containers — image and image ID, state and reason, restart count, ports, resource requests and limits
  • Conditions — the pod’s Kubernetes conditions with their transition times
Container environment variable names are shown; values are never exposed. Configuration passed as an environment variable stays readable only inside the container.
The panel also offers:
  • Delete pod — remove the pod. The deployment recreates it, so this is the standard way to recycle a single misbehaving replica.
  • Force delete — delete with a grace period of zero, for a pod that will not terminate normally.
Force delete skips graceful shutdown. Use it for a genuinely stuck pod, not as a faster ordinary delete — an application mid-write can be cut off.

​
Lifecycle actions

Undeploy is the reversible one: the microservice remains in the list and keeps its configuration, but nothing is running, so it drops out of the function stack host list until you deploy it again.

​
Deleting a microservice

Delete opens a dedicated panel with a danger alert and a type-to-confirm on the microservice name. Confirming tears down the running resources and removes the definition.
Deleting is not reversible, and any function stack still referencing the microservice will fail at runtime. Check what calls it before you delete it.