# The Helix dashboard

> A tour of the builder dashboard: workspace switcher, project cards, and the Overview, Scheduled Jobs, Access Control, Deployments, and Logs tabs.

The Helix dashboard at `https://app.helix.tray.ai` is the web console for everything running on Helix. It has two surfaces: the builder dashboard, where anyone with workspace access manages projects, and the [Admin console](/documentation/governance/admin-console/) at `/admin`, which org admins open for the org-wide view. This page covers the builder dashboard and Organization settings.

## The header

Every page of the builder dashboard carries the same header:

| Control | What it does |
|---|---|
| Workspace switcher | Moves between the workspaces you belong to |
| Admin | Opens the [Admin console](/documentation/governance/admin-console/). Visible only to org admins |
| Dark mode toggle | Switches the theme |
| User menu | Organization settings and Sign out |

If you do not see the Admin button, you are not an org admin in this organization.

## Workspace view

Switching to a workspace gives you two items in the sidebar:

- **Projects**: every project in the workspace, as cards.
- **Authentications**: the authentications available for projects in this workspace. Authentications are created in Tray iPaaS today, and org admins can see every authentication in use across the organization from the Admin console.

### Project cards

Each project card shows:

| Field | Notes |
|---|---|
| Name | The project name, generated on the first deploy unless you set one |
| Description | Written by AI from the project's code, and regenerated on every deploy |
| Connected services | Icons for the third-party services the project calls |
| Created by | Who provisioned the project |
| Last deployed | When the most recent deployment went out |
| Link to the published app | Opens the deployed app |
| Delete | Removes the project |

The AI-written description is worth reading when you audit a workspace: it is the fastest way to tell what an unfamiliar project actually does without opening its code.

:::note{title="Published app domain"}
Open an app from its project card rather than constructing or hard-coding its URL.
:::

## Project view

Opening a project gives you these tabs.

### Overview

Execution health for the last seven days: a success-rate gauge, a trend chart for errors and timeouts, and a list of recent deployments. This is the tab to check when someone reports that an app is misbehaving, because a degraded project shows here before anyone files a ticket.

### Scheduled jobs

Every [scheduled function](/documentation/guides/scheduled-functions/) the project's live deployment declares, one row each:

| Column | Contents |
|---|---|
| Job | The job's file name, the description its code carries, and a marker when the job allows overlapping runs |
| Schedule | The cadence in words, with the cron expression on hover. A job firing every 15 minutes or more often is flagged as high frequency |
| Timezone | The timezone the cron is evaluated in |
| Next run | A countdown and the local time of the next fire, derived from the cron expression |
| Status | Active or Paused |

Search by job name or description, filter by All, Active, or Paused, and read the active and paused counts beside the filter.

**Pause** on a row stops a job firing without touching the code, and **Resume** starts it again. A paused job stays paused through redeploys, so a deploy never quietly restarts it. The control is there for people who can change the project; a viewer sees the list read-only. **View logs** in the row's actions menu opens the Logs tab filtered to that job.

This is the tab to open when a job is calling a third-party system too hard, or when someone asks what this project does on a timer.

### Access control

Who can open the published app. The setting is one of Workspace (the default), Only people invited, or Organization. See [IT & governance](/documentation/governance/) for what each setting means and who can select it.

### Deployments

Every deployment of the project, newest first:

| Column | Contents |
|---|---|
| Status | Live, Deploying, Restoring, Restore failed, Build failed, or Superseded |
| Deployment ID | The identifier to quote when you raise a support issue |
| By | Who deployed it |
| When | When it was deployed |

A deployment created by restoring an earlier one also shows which deployment it restored. Selecting a row opens its build output: warnings, errors, and the authentications it declares.

**Restore** on a row rebuilds and redeploys that deployment's source as a new deployment. **Download** fetches that deployment's source, including for a failed build. Both need the same access as deploying the project. See [restoring a previous deployment](/documentation/guides/deployment/#restore-a-previous-deployment) for what restoring does and doesn't do.

### Logs

One entry per execution: HTTP requests that reached the app, and runs of its [scheduled jobs](/documentation/guides/scheduled-functions/). Each entry shows the time, the status, the trigger type (`HTTP` or `SCHEDULE`), the route or job that ran, the duration, and who initiated it.

Search the log by route, job, trace ID, or actor, and filter by time range, trigger type, actor, or whether the execution errored.

:::note{title="The log records runs"}
Every run that was dispatched gets an entry, including each attempt of a retried scheduled tick. Queue-driven executions are planned, so a log holding only HTTP and schedule entries is not a sign of missing data.
:::

## Execution traces

Clicking a log entry opens the execution trace for that one execution. The header of the trace carries the identifiers you need to correlate with anything else:

| Field | Use |
|---|---|
| Trigger | What started the execution |
| Environment | Which environment ran it |
| Trace ID | Correlates this request across systems |
| Execution ID | Identifies this one run |
| Deployment ID | Ties the run to the exact deployed version |
| Initiated by | The person or system that made the request |

Below that is the operations tree, a span-by-span breakdown of what the execution did:

- Calls to third-party services, with timings.
- Which authentication each call used.
- Key-value operations, with timings.

The trace also shows the request and response payloads for that execution.

:::warning{title="Traces can contain customer data"}
Request and response payloads are stored as they were sent. If an app handles personal or regulated data, that data appears in its traces. See [audit and compliance](/documentation/governance/audit-and-compliance/) for retention and access details.
:::

## Organization settings

Open the user menu and choose Organization settings. It has three tabs:

| Tab | Contents |
|---|---|
| Members | Everyone in the organization: name, email, role (Admin or Contributor), status, and how many workspaces they belong to |
| Workspaces | The workspaces you belong to |
| Other workspaces | Workspaces in the organization that you are not a member of |

The Members tab is where you check role assignments. Every role change is recorded in the [activity trail](/documentation/governance/audit-and-compliance/).

---

Canonical: https://helix.tray.ai/documentation/governance/dashboard/
Any link on this page is available as markdown by appending .md to its URL.
Full corpus: https://helix.tray.ai/documentation/llms-full.txt