Workspace Deployments
Monitor deployment activity across every Skytells project you can access, filter release history, and jump directly to the affected app.
Workspace Deployments is the account-wide timeline of app deployments from all projects you can access. It includes deployments for standard apps and app-derived types such as Compose apps and Drops, whether the project is owned by you or shared with you.
Open Projects > Deployments in the Console sidebar.
This page brings deployment history into one timeline; it does not change resource ownership. Every deployment remains scoped to one app in one project, and your project role controls which actions are available after you open it.
Understand the Scope
| View | What it lists | Use it when |
|---|---|---|
| Workspace Deployments | App deployments across all accessible projects | You need cross-project triage, release oversight, or audit history |
| App Deployments | Deployments for one app, including Compose apps and Drops | You need detailed logs, source context, or redeploy actions; see Compose Apps for the shared control model |
| Drop Deployments | Uploads, redeployments, and rollbacks for one Drop | You are operating a ZIP-based app through its dedicated Drop pages |
Drops appear in the workspace timeline because they share app deployment capabilities. Database provisioning and lifecycle events are not app deployments and are not listed here; use Workspace Resources to locate databases across projects.
What You Can See
Each timeline item identifies the deployment, its app and owning project, when it started, its current status, and available source context such as environment, repository, and branch. Repository and branch fields apply when the app has Git source; a Drop uses its uploaded archive as source instead.
Cross-project timeline
Review recent releases without switching between project dashboards.
Focused filtering
Filter by status, date, environment, repository, or branch to isolate the releases relevant to an incident or review.
Current status
The newest deployments receive live status updates while active builds settle into a terminal state.
Investigate a Failed Deployment
Open Workspace Deployments
Select Deployments under Projects in the main sidebar.
Filter to the Failure
Set Status to the failed or error state. Add a date range, repository, branch, or environment when the result set is large.
Confirm the Scope
Check the project and app before opening the deployment. Similar app names can exist in different projects.
Open the Deployment
Select the item to move into its app-scoped deployment detail, where you can read build output and inspect the source revision and trigger.
Verify the Running Service
After a successful redeploy or rollback, check runtime logs and app status. A successful build does not by itself prove the service is healthy under traffic.
Filters
| Filter | Best used for |
|---|---|
| Status | Finding active builds, failures, cancellations, or successful releases |
| Date | Reviewing an incident window or a release period |
| Environment | Separating production activity from previews or other environments |
| Repository | Following one codebase that deploys to multiple projects or apps |
| Branch | Auditing production branch releases or isolating preview work |
Filters are applied to the deployments already loaded in the timeline. Use Load more to extend the history when the release you need is older than the current page.
Status Freshness
The timeline loads quickly from deployment history, then checks live state for only the most recent deployments. This keeps workspace monitoring responsive without polling every historical release.
For an older deployment or a state that appears out of date, open the deployment or app detail and refresh there. Terminal states such as successful, failed, or canceled do not require continued live polling.
Workspace vs. App Deployment History
| Workspace Deployments | App Deployments |
|---|---|
| Aggregates all accessible projects | Shows one app only |
| Best for triage, audit, and release oversight | Best for detailed logs and app-specific actions |
| Filters by status, date, environment, repository, and branch | Keeps the full history in the app's operational context |
| Routes you to the affected app | Supports detailed inspection and redeployment |
Use the workspace timeline to find an event across projects. Then open the deployment in its owning app or Drop to diagnose it, read complete logs, redeploy, or roll back. App Deployments explains the detailed history shared by app-derived resources; Drops explains the dedicated Drop navigation.
Practical Workflows
Production release review
- Set the date to the review window.
- Filter to the production environment.
- Narrow by repository or branch if several teams shipped in that period.
- Open failed or unusually long-running deployments first.
- Record the app, source revision, and final state from its deployment detail.
Active incident triage
- Filter to recent building and failed states.
- Compare the incident start time with deployment timestamps.
- Open likely releases and inspect build and runtime logs.
- Redeploy or roll back only after confirming the affected app and project.
A workspace filter is an investigation aid, not an access boundary. Production safety still depends on project roles, branch controls, and deployment permissions.
Related
- App Deployments — move from the all-project timeline to the detailed release history and actions for one app.
- Drops — understand how ZIP uploads become app deployments and why they appear here.
- Compose Apps — understand how a multi-container stack is deployed as one app and why it appears here.
- Workspace Resources — locate apps, Drops, and databases across all accessible projects before opening their control panels.
- CLI Deployments — trigger or list deployments for a specific app from the terminal; the CLI command is app-scoped rather than a replacement for this all-project view.
- App Logs — distinguish deployment build output from the selected app's runtime logs.
How is this guide?