Workflows and Containers

Trigger a Workflow instance#

Enable Workflows in the active service profile, then open a Workflow and inspect its instances. Trigger an instance with the payload expected by your application:

{"orderId":"demo-001","requestedBy":"documentation"}

This is an illustrative payload, not a built-in Workflow schema. Inspect the returned instance and its current status before triggering another one. Repeated triggers can create distinct instances and repeat application work.

Read the execution timeline#

Select an instance and inspect its steps, timing, outputs, and errors. A step failure is different from an instance still waiting for an event. Use the lifecycle/event controls appropriate to that instance, checking the target identifier and expected event payload.

Local workflow discovery comes from supported Wrangler declarations. Finding a local declaration does not mean it has been deployed remotely. Match the configured class/binding to the remote Workflow before comparing runs.

Inspect Containers#

Enable Containers in the service profile and open an application from the Containers tree. The dashboard is an inspection view: it does not start, stop, delete, or deploy container applications.

Interpret missing information literally. Selected at runtime means the runtime chooses the image; Not reported means health was not supplied. Neither label should be read as a failed health check. Scheduling may be default or associated with a Durable Object, depending on the application.

Locate local declarations#

The Local Dev Containers entry opens the Wrangler configuration declaration. It is a configuration location rather than a live container instance. Use the remote application view to inspect runtime state and the project’s own deployment workflow to change its configuration.

Record account, application/Workflow ID, instance ID, and time range when diagnosing a discrepancy between the explorer, local declaration, and remote runtime.