Skip to main content

Dashboard overview

The dashboard is your organization's control center on the customer side of 4RGE. The overview page highlights operational health — agent runs, completed work, and active projects — while dedicated modules let admins manage members, model access, budgets, integrations, and settings. Platform operators manage contracts and capacity separately in the Console.

What's on the overview

The landing view is optimized for admins and leads who need a pulse check without drilling into every module.

WidgetWhat it shows
Agent runs (30 days)Count and trend of agent activity across surfaces
Completed workRecently finished tasks or runs (org-configurable attribution)
Active projectsProjects in active status with health indicators
Activity heatmapDaily agent activity intensity
Project progressPer-project breakdown of open vs done work

Members with standard org role see a focused subset — their projects, personal usage where permitted, and agent entry points — not full org admin modules.

Admin areas

Additional enterprise modules (teams, projects directory, repositories, audit, analytics) share the same shell and capability model — visibility depends on org role and granted capabilities.

How overview metrics are calculated

The overview page loads a 30-day window from x4rge_agent_runs (scoped by org RLS). KPI cards show Agent runs (total and average per day), Completed (finished runs vs in-progress), and Active projects (projects with at least one run vs total projects). The activity heatmap plots daily run counts; hover a cell to see the exact date and count.

In-progress runs include statuses queued, starting, running, and waiting. When the org has no runs yet, cards and the heatmap render zeroed placeholders rather than errors.

Recent activity

Below the heatmap, Recent activity lists the six most recent org audit events with actor, action, and relative time. Use View all to open the full audit log — helpful when troubleshooting membership, budget, or model policy changes that affect agent access.

Role access matrix

ModuleMemberAdminSuper admin
Overview (personal)YesYesYes
Overview (org-wide)LimitedYesYes
MembersDirectory only*ManageManage + ownership
Model controlNoYesYes
Usage / spendingOwn usage*Org rollupsOrg rollups
Budget policiesNoYesYes
Settings (general)Profile/sessionMost settingsAll + delete org
Audit logNoYes†Yes
IntegrationsUse if allowedManageManage

*Depends on org settings such as require project assignment and usage capabilities.

†When org.audit.view is granted to delegated admins.

Admin walkthrough: first week setup

  1. Confirm contract visibility

    Open Organization (or Settings → contract panel) and verify plan name, included monthly allowance, and renewal date — these come from Console contracts.

  2. Invite the team

    From Members, invite admins and contributors with appropriate roles. Default new members to member unless they need dashboard access.

  3. Curate model catalog

    In Model control, enable providers your contract includes, disable high-cost models you do not need, and set CLI/desktop/cloud defaults.

  4. Set a budget policy

    On Usage, configure a monthly USD cap and enforcement (warn, soft stop, or hard stop) so experimentation does not silently consume on-demand capacity.

  5. Connect GitHub

    From Integrations, install the GitHub app and link repositories to projects before enabling CI or cloud agents.

How dashboard relates to Console

LayerWho sets itWhat it controls
Contract / capacityPlatform operator (Console)Entitlement ceiling, included allowance
Org policyCustomer admin (Dashboard)Models, budgets, members, integrations
Team / project policyAdmin or delegated managerNarrower models, allocations, repo scope
Member workIndividual contributorsAgent runs inside effective policy
Note

Most admin actions require admin or super admin role. Members see a focused view of their own work. UI visibility is a convenience layer — Supabase RLS, RPCs, and capability checks enforce access server-side.

Use audit for changes

Budget, model, membership, and ownership changes are recorded in the org audit log. When troubleshooting "it worked yesterday," filter audit events by actor and action before re-running policy changes.