A L M A S ALMASHelp Open in the app

System dashboard — Development metrics & one-click deploy

This section is for system administrators. The tabs below only appear if your account has the system-admin role.

When you open the System dashboard as a system administrator, the charts are now grouped into tabs along the top so the page isn't one long scroll:

  • Operations — the charts you already know: live WebSocket connections, storage growth, AI usage, and API-key usage.
  • Development — how the product itself is being built, month by month.
  • Deploy — check for and apply application updates without touching a terminal.

The Development tab

This tab visualises every commit made to ALMAS since January 2020, classified by what it was — a new feature, a bug fix, a small or large UI change, and so on.

  • Summary cards at the top: total commits and lines of code for each side of the product (the API and the web app).
  • Commits per month — a bar chart. Click any bar to open a drill-down table listing that month's commits: what kind of change it was, which part of the product, a short plain-English summary, and how many lines it touched.
  • More charts below break the same data down by category (features, bug fixes, UI work), show the mix of work over time, and track total lines of code.
  • A milestone timeline highlights the months where something significant shipped.

Click Refresh (top-right of the tab) to re-scan for any commits made since the last build. You'll see a short "refresh started" message; the charts update themselves a few moments later when the scan finishes — no need to reload the page.

The Deploy tab

This tab lets you apply a pending application update — the same thing an engineer would do from a server — guided step by step.

  1. Click Check for updates. ALMAS looks at what's waiting to be deployed and shows you two things: a plain-English summary of what the update will do, and a table of the individual changes (new commits, database migrations, release steps).
  2. If everything looks right, click Deploy. For safety, a box asks you to type the name of the branch you're deploying. This is a deliberate speed-bump — if you type the wrong name, the deploy won't start.
  3. Once confirmed, a live log streams each step as it happens. When it finishes you'll see the generated changelog of what changed, and the Development charts refresh automatically to include the new work.
  4. The Deployment history list at the bottom records every past deploy — who ran it, when, and whether it succeeded. If a deploy went wrong, Rollback reverts the most recent one.
  5. Download latest run log, at the top of that list, saves the full, detailed record of the most recent update, whether it was started from this tab or by an engineer on the server. The line under the list title shows when that update ran, how it ended (succeeded, succeeded with warnings or failed) and how many problems it reported. When an update reports problems, send this file to your support team or to an AI agent: it holds every step and error message, with passwords and keys masked.

Where this works: the Deploy button operates on servers ALMAS runs on directly (your local or EC2-style environment). On fully serverless hosting it shows a notice that one-click deploy isn't available there — those environments are updated through their own pipeline.

Tips

  • The Development tab is read-only — anyone with the system-admin role can look. Deploying is a separate, stronger permission; if you can see the Deploy tab but the buttons are greyed out, you have read access but not deploy access.
  • Use Check for updates freely — it only previews. Nothing changes until you confirm the branch and click Deploy.
  • Download latest run log is shown only to people with deploy access. It stays greyed out ("No run logs yet") until the first update has run.
  • If the Development charts look empty the very first time, click Refresh once to build them.

The Operations tab — AI calls, activity and storage

The Operations tab opens on the last 7 days. The buttons above the connections chart switch the range — 7 Days, Month, 6 Months, YTD, Year, 3 Years — or pick your own dates with the calendar. The AI cards, the connection numbers and the Activity card all follow the range you choose.

See every AI call. In the AI cards, the numbers are links:

  • Total AI Calls (and the red N failed next to it), Successful Calls and Failed Calls open a window listing those calls for the range — when, which tenant, who, which feature, the model, tokens, cost and how long it took. Narrow it with the status, tenant and feature lists, or search for an error message, a model or a person.
  • Click a call to see it in full. A failed call shows its error in red; a successful one shows the request sent to the AI and the response it gave. Every call says what triggered it — a page in the app, a background job or a scheduled task. Show raw payloads reveals the complete technical data.
  • The text of calls older than 90 days is removed automatically to protect privacy; their numbers (tokens, cost, errors) stay in the totals, and the call says when its text was removed.

Who is active. The Activity card shows, for the range:

  • Unique logins — how many different people signed in (each person once, however many days they came back).
  • New users — people who joined; system and AI-employee accounts are not counted, and customer-portal contacts are shown separately underneath (+ N portal contacts).
  • New tenants — workspaces created.
  • Avg connection time — how long people keep ALMAS open, and a table with one row per tenant: connected people, sessions, average and total time connected. The busiest tenants are at the top.

The WebSocket Connections card also shows Unique Users — how many different people were connected in the range. Connection times are measured from the moment this version of the app is in use; older visits count as visits but have no duration.

Storage growth per tenant. The Storage added per tenant (30 days) pie shows which tenants uploaded the most in the last 30 days, with the size and share of each (the eight largest, the rest grouped as Others). It always covers the last 30 days, whatever range is selected, and counts uploads — files deleted later are not subtracted.