dFlow surfaces health

through deployment status, proxy reachability, scaling state, and logs. There is not a separate customer-facing “health check editor” in the dashboard today; probes follow the buildpack or container defaults on the Worker Node.

Deployment status

Each row on the Deployments tab shows a status badge (for example success or failure). That badge reflects whether the platform finished the last build or rollout step it tracks for that record.

• Use View Logs on the row for the failing attempt before changing code.
• Repeated failures after Redeploy often point to build, dependency, or start command issues (see Deployment issues under Troubleshooting in the sidebar).

Queued operations

Many mutating actions (deploy, restart, stop, domain updates, scaling changes) enqueue work on the Worker Node. Toasts frequently say Added to queue. The Queues panel (when available in your layout) lists outstanding jobs.

Expect short delays between clicking an action and seeing runtime effects.

Restarts triggered by configuration

Some updates explicitly restart processes so edge settings apply. Example: after certain Proxy / Nginx parameter saves, the UI toast mentions restarting the Service for the change to take effect.

Live logs

The Logs tab opens an EventSource stream of runtime messages for the Service. Logs are best-effort: if the process crashes before streaming, fall back to Deployments logs for boot errors.

Database exposure guardrails

Stop is blocked while a database Service remains Exposed. Unexpose first; this prevents accidental data exposure while the instance is torn down.

Scaling and capacity

Scaling shows replica badges per process. A value of Not Set means the defaults apply. Hitting maxReplicas or memory ceilings surfaces as errors in toasts or deployment output rather than a separate health widget.

Related

• Logs

• Redeploy and rollback

• Scaling

• Logs and debugging