Operating

Once your app is installed, App Studio in the Cockpit is where you watch it and change it. This page is what each screen is for and which question it answers, so you know where to go at the point something is wrong.

Deployments

Every version you have built, when it was built, whether the build succeeded, and which one is active.

Use it to answer "what is actually running?" — the first question in almost every investigation, and the one people assume they know. A tenant can be on an older version than the one you deployed last, and a build that failed leaves the previous version serving.

For a git-wired app, this screen also shows each deployment's commit. A deployment with no commit association is the fingerprint of a CLI deploy onto a git-wired app.

Executions

One record per invocation: when, what triggered it, how long it took, the status, and the log lines your handler wrote with c.log().

This is the screen you spend the most time in. It answers:

• Did the call reach me? A request that is not here was rejected by the gateway before your function ran — usually contract validation.
• Did the schedule fire? Ticks appear here like any other invocation, with the schedule name.
• Did the event arrive? So does an event delivery. This is how you find out whether an event you listened for is real. See Events you receive.
• What did my handler think it was doing? Whatever you logged.

Which is the argument for logging deliberately: one line per invocation with the request id, the tenant and the outcome turns this screen into something you can search. And the argument against logging carelessly: never log a sensitive setting or personal data, because this screen is readable by whoever operates the tenant.

Variables

Environment variables for the app, per tenant. This is where the OTEL_* tracing configuration goes, and any other non-secret configuration your runtime needs.

Two things it is not:

• Not the place for merchant configuration. Anything a merchant should be able to change belongs in settings.json, where it gets a form, validation and per-market resolution.
• Not a secrets manager. A value a merchant supplies belongs in a sensitive setting; the secret grant is not yet proven.

Changing a variable is an operational change, not a deploy. Note that a change takes effect for new invocations, not for one already running.

Usage

Invocation counts, durations and error rates over time.

Use it for the questions a single execution cannot answer: is the error rate rising, is the p99 a real tail or one pathological request, did that release change the shape of the traffic, and is this app being called at all. An app with zero invocations after a launch is a routing or install problem, not a code problem.

It is also where you notice a job whose cost grows with the tenant — a nightly task that took two seconds at launch and forty a year later. See Scheduled work.

Traces

The per-invocation spans, when you have configured an OTLP endpoint. Free and empty when you have not.

Executions tell you that an invocation was slow; traces tell you where. Use them for the two questions that matter most in a commerce app: is my own code slow, or is something I call slow — another app's capability, or an external host. Forwarding X-Request-ID is what makes that chain one trace instead of three. See Tracing.

Settings

The rendered settings.json form for this tenant: the current values, per market where a key is market-scoped.

Use it to answer "what is this tenant actually configured with?" — and to check the form you shipped is one a merchant can use, which is easier to judge here than in the JSON. The settings endpoint gives you the same answer from a terminal.

When an operator reports that a change had no effect, this screen plus the market they were testing with usually explains it.

Anatomy

What the app declares, as the platform understands it: its entities, its capabilities and routes, its grants, its events and schedules.

This is the screen for "is what I think I declared what actually got applied?" It is generated from the applied version, not from your working copy, so it is the authoritative answer when a route is missing or a grant is not doing what you expected. Read it alongside the published OpenAPI document, which is the same information from the caller's side.

Which screen for which question

Next steps

• Verifying live — the calls to make before you read any of these.
• Tracing — turning the traces screen on.
• Deploying — shipping the fix you just found.
• Apps command reference — the same objects from the CLI.