Tour the dashboard

Product tour

The Greenlight dashboard is the single operational surface for IT — every app, integration, grant, user, and audit event in one place. This page is the five-minute visual map: what each screen shows, with a link to the page that explains how it works.

Apps

The fleet at a glance, and where most day-to-day work starts.

• Every app in one list — status, owner, and Last Updated: when it last deployed, with the outcome of that pipeline run beside it.
• Usage for IT — how many people used each app over the last week, with request volume beneath. The list sorts by that headcount.
• One alert when something needs you — it appears only when apps have failed or degraded, or their latest pipeline run failed. Its button filters to exactly those apps, the same set as the Needs attention filter.
• Filters and sort — Add filter narrows by status and tags; each filter is a chip you can change or remove. Sort orders the list or grid.

More detail: live updates, the Org Owner banner, and what builders see

• Apps and their deployment status update automatically: about every 15 seconds, or every 5 seconds while work is in progress. Updates pause while the browser tab is hidden and resume when you return. The Marketplace refreshes automatically too.
• Building and deploying badges show a spinner beside their steady yellow indicator, with motion disabled if you prefer reduced motion.
• New apps appear in the current matching list without clearing your search, filters, or selected view.
• Org Owners get a banner above the list: the total number of live apps, then three numbers for the last 7 days. Those are updates shipped (successful deploys), active users (people who used any app), and data requests (calls Greenlight brokered from your apps to connected systems).
• Citizen developers also see the org’s available integrations, by name and logo, so they know what to ask their agent to build with. A long list stays behind View more.
• Who can use an app is set on the app’s own Access tab, not from this list.

App detail

Clicking an app opens its own small dashboard, grouped into five tabs. → App deployment & isolation

Tab	What it shows
Overview	A system map of the app’s workloads, provisioned resources, and connected integrations
Deployments	Pipeline runs
Access	Who can use the app, and its permissions
Monitoring	Resource metrics, usage analytics, a diagnostics snapshot, and logs
Configuration	Environment variables

The header carries a power menu for lifecycle actions: pause, restore, and delete.

More detail: monitoring and the app’s URL

• When an app is crash-looping, a banner above its logs names the restart count and exit reason.
• The diagnostics snapshot shows pod and probe health, which expected env names are missing or stale, whether each dependency answers, whether the newest merge reached the cluster, and who must act on a stuck rollout. It refreshes when you ask.
• Current resource metrics and usage update every minute.
• The owner or IT can edit a deployed app’s URL from the header: pick a new subdomain under the apps domain and every link follows. The old address stops working immediately, with no redirect.

Access tab

One list of everyone who can open the app: its owner, the people named on it, and the groups bound to it. The integrations the app itself may reach sit below. → Identity, SSO & RBAC

• One search box adds all three. Start typing a colleague’s name or email, or a group’s name, and pick from the results.
• Groups show who they admit. Each shows how many people it admits and expands to name them, so you see who you are letting in before you decide.
• Group editors need a confirmation. Making a group an editor asks you to confirm and says how many people that is, because an editor can delete the app. For a directory group, the count is how many members have signed in so far. Making one person an editor needs no confirmation.
• Nothing to paste. Directory groups appear under the name your Org Owner gave them when registering.

Pipeline runs

Every pull request’s run, with a verdict per check and the OPA decision in full. → Source control & the policy check

• The checks — secret scanning, dependency scan, SBOM, policy engine, build, deploy, and Greenlight’s own check that the run and its evidence came from the pipeline it installed.
• Release notes — deploy runs carry the merged pull request’s title and body, so you can tell what each release changed without opening GitHub.
• Live status — an open run updates its status and check verdicts every 5 seconds until it finishes. Raw logs load when you ask for them, and status stays current while they do.

More detail: skipped scan checks on a merge run

A merge run may show its scan checks as skipped, with a note naming the earlier run its findings came from. The content was identical, so Greenlight reused evidence it had already verified rather than scanning the same files twice.

Marketplace

Browse the live apps your colleagues have built and open them: one card per app, with its icon, cover, owner, tags, and summary. It is always available to everyone signed in.

• You only see apps you can open. A restricted app is listed to the people named on it and the members of groups bound to it, and to nobody else. There is no locked card and nothing to request: if you can’t find an app you’ve heard about, ask its owner to add you.
• Star and hide are just for you. Nobody else’s view changes, and neither affects who can open the app. Starred apps sort to the front, across pages too.
• Hidden apps come back. They drop out of your catalog and return through Show hidden apps, where you can unhide them from the card. Hiding also offers an undo.

Integrations

One tab for the org’s outbound integrations and the grants apps and people hold against them. A control switches between two views.

Integrations view

• Requests to connect — a panel at the top when someone’s agent asked for a system your org hasn’t connected. It shows who asked and why, with Approve & register, which opens the Register dialog already filled in, or Decline, which asks for a reason. Requests are never auto-approved, and approving on its own connects nothing.
• One card per upstream service — logo, name, an availability switch, and a Review needed badge when something is waiting.
• One line per credential — slug, description, auto-approval switch, and Edit and Delete. Everyone who requested or holds it sits behind an Access granted to dropdown, where you approve, deny, or revoke in place.
• Register from the catalog — a searchable, logo’d catalog (GitHub, Slack, OpenAI, Salesforce, Snowflake, …), or a Custom path for anything not catalogued.

→ Manage integrations

More detail: editing and deactivating an integration

• Base URL, auth mode, and delivery stay behind Edit integration rather than on the card.
• Making an integration inactive keeps it visible to IT while hiding it and its Knowledge from agents until you reactivate it.

Grants view

The org-wide inventory of which access holders, apps and people, hold which grants. Group it by integration or by access holder, and triage pending requests in place. Personal requests made through a user’s agent or CLI land here beside app requests. → Governance & policy

Knowledge

Org- and app-scope entries, plus the queue of agent proposals to review, accept, or reject. → Curate Knowledge

Audit

Audit health, live write throughput, and the queryable log of every governed action. Filter by event, app, actor, and time range. → Observability & audit

A User attribution panel answers what the log itself can’t: which apps record data calls without naming the person behind them, and which simply have no person to name.

Compliance

The SOC 2 common criteria laid against the Greenlight mechanism covering each one. → Compliance

• Every row links to its live proof.
• The whole mapping exports as JSON or CSV for your compliance platform.
• HIPAA and GDPR sections appear on the same page when the installation is in that framework’s scope.

It reports control coverage and evidence for the apps Greenlight governs. It is not a certification claim.

Users & RBAC

The user directory, and the table that maps IdP groups to Greenlight roles. → Identity, SSO & RBAC

• User inspector — selecting a user shows their identity and groups, the apps they own or edit (each links to that app), and the restricted apps they are named on. Apps open to the whole organization aren’t listed, since everyone can reach those. For Admins and Org Owners, who can open every app, it says so instead of listing grants.
• Log in as — Org Owners can see the dashboard as an Admin or Builder. It is audited, with a Stop banner.
• Groups — an Org Owner curates the named sets of people the organization works with.

More detail: the two kinds of group

• Greenlight groups are created and membered here, for sets your directory does not model. Their membership is yours to edit.
• Directory groups are registered by pasting the group’s identifier from your IdP once and giving it a name. Membership is whatever your IdP says, shown read-only and covering the people who have signed in to Greenlight.
• A group in use by an app can’t be deleted or deregistered until it is released there first.

Apps nobody is using

Greenlight can pause apps that have gone unused, so your estate does not fill up with forgotten apps that still hold access to company data. It is off until an administrator turns it on, under Settings → Unused apps.

1. Set two day counts in Settings → Unused apps: how long an app must be quiet before its owner hears about it, and how long before it is paused.
2. Greenlight checks once a day. A quiet app’s owner gets one email, your app is scheduled to be paused, linking to the app’s page.
3. The owner stops it by opening the app, which resets the clock, or by confirming it is still needed. The app’s page shows the same warning as a banner with both options.
4. Otherwise the app pauses at the second threshold: it stops serving and its access to your data is revoked. Nothing is deleted, and the app can be restored from its page at any time.

On the apps list, an app heading for a pause carries a Scheduled to pause badge, and administrators get a Last Used column. Apps that are idle by design, such as a monthly job, can be exempted.

Internal health

The control plane’s own health. The current status and three readings sit at the top, above three tabs: Cluster health, Updater health, and App health. Each tab is its own link you can bookmark or share. → Upgrades

The headline judges each service by what breaks when it is down and names the one in trouble. Ingress down is red, because nobody can reach anything. Certificates down is amber, because nothing fails until one falls due.

Cluster health

• Kubernetes cluster health names the managed Kubernetes service your install runs on (AKS, GKE, or EKS) and says in a line what a node and a pod are.
• Cluster capacity shows CPU and memory reserved on ready nodes as two bars, then every node: what it offers, what Kubernetes leaves allocatable, and who reserved it.
• Greenlight control plane services lists every service Greenlight runs in your cluster, with each replica’s CPU and memory against its limits, its restarts, and why it last restarted.
• Release and resources — the release version and commit, database connections, and the status of the cloud resources behind your install.
• Upstream services — GitHub and the coding-agent vendors (Anthropic, OpenAI, Google AI, Cursor).
• Fleet Reporting — exactly what your install shares with Shift.

More detail: cluster capacity and growth

• Each node’s reservations are split between Greenlight’s control plane, your apps, and the cluster’s own system pods.
• Dashed slots stand for the nodes added automatically if the others fill up. Only when something is wrong, a line names any app pod that is waiting for room.
• Under the two bars, a line says how many more small apps fit before the cluster adds a node, and the most room any one node has left. Your cluster adds a node only when an app fits on no running node, so a high percentage alone does not mean a node is coming.
• Can grow to shows how many nodes the cluster may grow to, with − and + to change it. The updater applies the change at the next update window or at once.
• More options holds how many nodes stay on when idle and how many run Greenlight itself.
• When apps are waiting because the cluster is at its limit, a line asks you to raise it.
• A lower limit is accepted only when the apps on the nodes it removes fit on the nodes that stay. Otherwise the card says there is not enough room and to remove some apps first.
• One line names the last change and whether it applied.
• Greenlight and your apps share nodes until one is full, so there is one picture of the machines rather than one per plane.

More detail: control plane services and cloud resources

• The services are the primary server (the dashboard, the APIs, and sign-in for every app), the async worker (deployments and background jobs), ingress (how every request reaches the dashboard and your apps), certificates (the TLS certificates they are served with), and the screenshot renderer.
• A replica that ran out of memory overnight still says so in the morning, because the last restart reason is kept.
• The cloud resources are the compute cluster, database, secrets vault, registry, storage, and DNS.

More detail: upstream services, egress, and banners

• Greenlight never calls the agent vendors on your behalf, so their own status page is all it knows. The section says so once, and labels a row only when Greenlight measured it itself.
• On a private install whose outbound traffic goes through your firewall, an Egress section lists every destination that firewall must allow. Greenlight’s own come first, each with the reason it is needed, then each registered integration’s upstream. Each shows whether Greenlight reached it at the last check, and names the stage that failed for a blocked one.
• Opening the Egress section checks again when the last check is over a minute old, and Check again runs one on demand. Other installs have no Egress section.
• When GitHub is impaired, everyone signed in sees a banner naming what may fail, so nobody spends the outage assuming they broke something.
• A GitHub Actions billing block is different: only admins can fix it. While GitHub refuses to run your organization’s pipelines, admins see a banner on every page linking to GitHub’s billing settings, and builders learn it from their run’s own check.

More detail: what Fleet Reporting shares with Shift

• The one-time enrollment payload: installation id, key hash, org name, tenant id, and region.
• The latest health report delivery with its exact JSON: redacted operational summaries only, never customer data.
• The summary includes the control plane services card: each service’s ready replicas and, for up to five replicas, their CPU and memory against their limits, restarts, and last restart reason. Shift can see a service in trouble without asking you.
• Failed pipeline checks appear as a check name, app slug, timestamp, and count. A check’s output quotes your source, so it stays out of the report and travels redacted as the failed run’s failure log instead.
• A list of Greenlight’s scheduled jobs: whether each one’s last run succeeded, when it last did, and how many runs in a row have failed, never the error text. If the health snapshot itself stops being recorded, the window still goes to Shift as a short report carrying only that list, so Shift sees a failing install rather than a silent one. Only a full report counts toward the reporting requirement.
• An inventory of what your install brokers to: how many integrations you registered, which catalog entries they came from, and for ones you wired up yourself the vendor’s registrable domain, so api.gusto.com is shared as gusto.com. Your integration names are never sent, and anything pointing at an internal or private host is shared only as private.
• Redacted failure logs travel on their own channel, not in that payload. Each failed update run’s and failed pipeline run’s log, the captured log of a crashed Greenlight service, and a failed scheduled background job’s log is always sent. An app crash’s log is sent only when you choose to share it.
• Every send is recorded in your audit log (Failure logs sent to Shift).

Updater health

• Where you stand — whether you are current or a newer release is waiting, and when the next run is due. The schedule, time zone, prerelease posture, and last check and apply sit under a details toggle.
• Update runs — eight at a time, with Previous and Next. Checks that found nothing to take are hidden by default, and one toggle shows them.
• Each run — every phase with its duration and reason, the exact non-secret inputs it replayed, and its full log, downloadable long after the run’s pod is gone.
• Preview update plans an update without applying it. Apply now runs it immediately instead of waiting for the maintenance window. Both are for organization administrators only, one run at a time, and audited.

More detail: run states and freshness

• The full log covers the infrastructure plan, application rollout, and installer output.
• While a run is in progress the list says so and keeps itself current. Refresh re-reads it on demand.
• The list pages rather than growing, so the page stays where you left it.
• A run that applied its release but failed one closing check is labelled as exactly that, not as a failure.
• A run whose Job finished without reporting reads as its own state.
• A scheduled run that waited out another run shows as Skipped, naming the run it waited for.
• The header says when the last reading was taken and counts up as you watch. Once nothing has been collected for a few minutes it says so and stops claiming the install is healthy.

App health

• Status counts — how many apps are active, degraded, failed, or suspended.
• App crashes — containers your apps exited from: which app, a plain-language kubelet reason with the exit code, and when. A line notes that a failed pipeline check is a different surface.
• Reserved but unused by app — running apps holding capacity they do not spend: what each reserves, what it uses, and a link to the app. An app whose usage was not measured is counted, not ranked.

More detail: sections that only appear when needed

• Queue health appears only when a job is waiting, has been held far longer than it should be, gave up after its last retry in the past day, or failed, or when one of Greenlight’s scheduled jobs is failing or overdue. A scheduled job is named for what it does, such as Recording control-plane health, with since when and a link to its last failed run’s log, kept even after the worker that ran it is gone.
• The latency panel waits until it holds a real measurement.
• Sections with nothing to report stay off the page rather than showing reassuring zeros.

More detail: History panels

• Each card has a History panel, collapsed under its current figures, that charts the same readings over a range you pick: 1h, 24h, 7d, or 30d, with 24 hours by default. Each panel keeps its own range.
• Incidents and release changes are marked on the same timeline.
• Cluster capacity charts CPU and memory reserved as two lines, each matching the dot beside its total.
• Each control plane service has its own History panel: memory and CPU with one line per replica, restarts, and ready replicas, with only its own incidents marked. The async worker’s also shows how long the oldest background job waited.
• Postgres connections shows each database. The latency card shows request latency against its targets and the server error rate.
• An interval nobody observed stays a gap rather than being drawn as quiet, and a line beside the range says how much of it was observed.
• Every chart can be read from the keyboard or opened as a table. Choosing a range never changes the current status at the top of the page.

Feedback

Where builder agents file platform-experience reports and dashboard users file UX reports, through the Send feedback dialog on every page. Org admins triage the combined list.

Tab	What it lists
Agent feedback	Bugs, friction, and ideas from agents and users. Filter by source, status, and category, and see who sent each item
Pipeline failures	Every failed pipeline run across your apps, newest first, with the app, branch or pull request, and the check that failed
App crashes	Each time an app’s container exited abnormally, with the reason, how many times it looped, and its last output, redacted
Health alerts	Each time an app started crash-looping, with the restart count and whether Slack or email was notified

• Hand items to Shift — select items and Download them as Markdown or Send to Shift. Feedback carries the report’s title and body but not who submitted it.
• Nothing leaves without you — a Settings → Organization switch, off until you turn it on, sends new feedback automatically. A second sends new crashes. An alert never reaches Shift unless you send it.
• Untrusted by design — feedback content is capped, rendered inert, and rate-limited.

More detail: how the tabs behave

• Handed-over feedback moves to the bottom of the list rather than out of it, and archive files items into their own view.
• With Agent reports on, the Claude Code plugin also files reports when an agent works around a Greenlight problem. Those carry an observer badge, and reports of the same problem on one page collapse into one row with a count.
• Pipeline failure rows open to the run’s checks and logs, and say whether Shift has the run’s failure log and why one is still sending. Pipeline failures download as Markdown.
• Crash rows say whether Shift has them, and download with their logs as Markdown.
• Health alert rows say whether Shift has them.
• The actions always sit above the list, disabled until you select a row, and each tab offers only the actions that apply to its rows.

And the rest

Settings

Org-level configuration. Each tab in a line:

• SSO — including reconfiguring or swapping the identity provider.
• Plugin sign-ins — the one tab every signed-in person has. It lists the sign-ins that let the Greenlight plugin act as you and ends any of them.
• Source control — branch policy, read-only, plus the GitHub App lifecycle and plugin marketplace repositories.
• Agent setup — rollout instructions for the agent and marketplace repository you select.
• Notifications — app health alerts, permission requests, requests to connect a new system, and a weekly digest, by email or Slack.
• Unused apps — pausing apps nobody uses, covered above.
• Organization — switches for Agent reports, Build token usage, and Sharing with Shift, plus the Shift contact.

More detail: plugin sign-ins and source control

• Each plugin sign-in shows when it happened, how, and what the client called itself. Ending one also signs you out of local data access on every machine.
• Admins can widen the list to everyone in the organization and end someone else’s sign-in. That is how a compromise gets contained without deactivating the person’s account.
• Branch policy is enforced at registration, not editable here.
• The GitHub App actions are verify repo access, re-create the App, and migrate the org to a different GitHub organization.
• For plugin marketplace repositories you can create public or private sources, inspect all managed rows, recreate one deleted on GitHub, or unregister one Greenlight should stop managing. Unregistering leaves the repository untouched on GitHub.
• For Claude, Cursor, and Codex, Agent setup also shows the organization policy that lets Greenlight actions run without a separate approval click, without weakening each agent’s controls for unrelated tools.

More detail: notifications

• Health alerts cover an app that keeps crashing or failing requests. For administrators only, they also cover an app whose data access suddenly spikes, or that tries to call an integration it has no grant for.
• Deploy and pipeline failures are inspected on app and pipeline surfaces, not routed as alert categories.
• All four categories are on from the start, but health alerts go only to Slack until you turn on Email health alerts. That also mails the app’s owner as well as your administrators. The section says plainly when your install has no email sender.
• A Slack channel can receive app health alerts, permission requests, and requests to connect a new system. Paste the incoming-webhook URL Slack gives you. Greenlight stores it without ever showing it again, so you replace it rather than read it back.
• Replacing the webhook keeps the channel name unless you clear the field. Removing it asks you to confirm, since a removed URL can’t be recovered.
• Registering the webhook does not switch it on. If a post ever fails, the section tells you instead of leaving a switch that looks fine.
• The digest arrives Monday morning. It leads with the Knowledge your agents proposed that nobody decided on, then the review queues still waiting and any app still crashing, how your apps were used, and one pointer at something Greenlight does that you may not be using. A week with nothing to say sends no mail.
• Pausing unused apps is its own section, because the same switch governs both the warning and the pause.
• App-pod egress lockdown is not on yet. When it ships it will live here as an off-by-default toggle plus a host allowlist.

More detail: Organization switches

• Agent reports, off until you turn it on. The Claude Code plugin reads each builder’s session on their machine and, when an agent hit Greenlight errors and found a way through, may file one summarized report per session into your Feedback page. Only those Greenlight calls and their results, with ids and secrets removed, go to a small Claude model that decides, through the builder’s own Claude sign-in. The rest of the conversation never leaves the machine, builders are not told in the session, and nothing reaches Shift unless you send it.
• Build token usage, off until you turn it on. The Greenlight plugin sends each coding session’s token counts to your install when the session ends, so Cost can show the token cost of building each app. Only counts per model and app are sent, never prompts, transcripts, or file paths, and nothing goes to Shift. Builders on seat plans are not charged per token, so the figure is what the same tokens would cost at the vendor’s API prices, not a bill. Sessions before you turn it on are not counted.
• Sharing with Shift, two switches, both off until you turn them on: send platform feedback automatically, and send app crash logs automatically.
• Shift contact — the administrator Shift reaches about your trial and subscription, named during install and changed here whenever that person changes. The card restates what is sent and shows “Not set” if your install predates the step.

Policies

Settings → Policies lists every shipped check with its state and whether it blocks or warns. It also holds the values the configurable checks compare against, the checks you require from your own scanners (or paste for Greenlight to run), each app’s latest gated run, and how long the audit log is kept. You tune the checks Greenlight ships; you don’t author rules here. → Manage policies

Cost Coming soon

What Greenlight costs you, per app and for the whole install. Organization administrators only, and behind a preview flag until it ships.

• Each app’s deployments, monthly active users, and app-hours, priced at your own rates with Shift. When those can’t be read, it uses the published list rates, labelled.
• Any monthly fee, shown once for the install.
• Month-to-date, projected for the month, and since the app was created, plus which apps sit idle.
• With token usage reporting on, the token cost of building each app, as an API-equivalent figure rather than money spent.

It does not estimate your cloud bill, and it is never an invoice.

Billing

Settings → Billing is for org admins only. It shows:

• Your license and its date, your billing account’s standing, and your terms in plain words.
• The last bill and whether it has been collected.
• What this install has measured this month under those terms: live apps on a per-app plan, or deployments, monthly active users per app, and app-hours on a usage plan. This is measurement, not an invoice.

More detail: payment

• If Shift collects by card, Set up payment method or Manage billing opens a secure page hosted by Shift’s payment provider. Greenlight never sees card details.
• A card is due within seven days of installing. Until one is saved, this page and a banner on every dashboard page name the day new building pauses. After that day, creating and deploying apps waits for the card while running apps keep serving.
• If Shift invoices you directly, the page says so instead.
• If you bought Greenlight through Azure Marketplace or AWS Marketplace, your cloud provider bills you, and the page points you to its console for your subscription, invoices, and payment method.

Maintenance

Settings → Maintenance shows the update schedule, its time zone, the next run, and your prerelease posture, read-only. Run history and logs are on Internal Health. → Upgrades

What’s not in the dashboard

A few things deliberately aren’t here, because they belong somewhere else:

• App code — the source of truth is your SCM. The dashboard links out to the repo for every app.
• Long-term log analytics — ship cluster logs to your own aggregator. The dashboard’s logs view is for the live tail.
• Secret values — the dashboard shows that a secret exists; you read its value (if you have permission) through your cloud’s vault UI.
• End-user analytics for an app — the app’s owner builds that into the app, or hooks the app up to a real analytics product.

Next

How it worksThe five steps from idea to governed production.

Admin guideInstall, configure, and operate Greenlight.

Security postureThe one-page summary for security reviewers.