Learn Dynatrace Master Complexity
“Real environments. Zero friction. Empowering everyone”powered by Orbital
The delivery backbone behind every WWSE enablement — provisioning live Kubernetes environments, running the CI fleet, and driving instructor-led workshops at scale.
Dashboard access is limited to members of the Dynatrace WWSE GitHub organisation. Registering a tenant needs no account.
| Repository | Arch | ARM64 | AMD64 | Branch | Actions |
|---|---|---|---|---|---|
| Loading repos… | |||||
| Repository | Branch | Arch | Action | Worker | Started | Elapsed | Actions |
|---|---|---|---|---|---|---|---|
| Loading running jobs… | |||||||
Deferred · queued behind a held lock
| Triple (repo : branch : arch) | Depth |
|---|---|
| — | |
Queued · waiting for a worker
| Repository | Branch | Arch | Type | By | Queued | Actions |
|---|---|---|---|---|---|---|
| — | ||||||
| Started | Repository | Branch | Arch | Duration | Status | Action | Trigger | Tenant | User | Daemon | Worker | Log | Rerun |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Loading history… | |||||||||||||
Recent runs
| Started | Command | Duration | Status | Triggered by | Log |
|---|---|---|---|---|---|
| Loading sync history… | |||||
| Repository | Pinned version | Latest version | Drift | CI | Automation |
|---|---|---|---|---|---|
| Loading status… | |||||
| Repository | # | Title | Author | CI | Labels | Updated | Fix |
|---|---|---|---|---|---|---|---|
| Loading PRs… | |||||||
| Repository | # | Title | Author | Labels | Updated | Fix |
|---|---|---|---|---|---|---|
| Loading issues… | ||||||
Fix with AI
Claude analyzes failed integration tests, determines whether the root cause is in the repo or the shared framework, then creates a fix branch and opens a PR.
agent readyRunning Agents
| Repository | Branch | Type | Started | Elapsed | Log |
|---|---|---|---|---|---|
| — | |||||
Reported agents
| Kind | Name | Owner / tenant | State | Stage | Started | Loop | Heartbeat | Cost / budget | PR |
|---|---|---|---|---|---|---|---|---|---|
| — | |||||||||
| Started | Repository | Branch | Type | Status | Duration | Log |
|---|---|---|---|---|---|---|
| Loading… | ||||||
Reported agents
| Last report | Kind | Name | Owner / tenant | Final state | Stage | Started | Cost · PR |
|---|---|---|---|---|---|---|---|
| Loading… | |||||||
| Repository | Branch | Arch | Failed step | Status | Failed at | Duration | Log | Fix |
|---|---|---|---|---|---|---|---|---|
| Loading… | ||||||||
| Repository | # | Title | Author | CI | Updated | Fix |
|---|---|---|---|---|---|---|
| Loading… | ||||||
| Repository | # | Title | Author | Labels | Updated | Fix |
|---|---|---|---|---|---|---|
| Loading… | ||||||
Loading workers…
Queue Depths
Tests
Unit, framework, integration and end-to-end — the four layers a change passes, cheapest first.
Unit — GitHub Actions
runs on GitHub runners on every push and PR — not on the fleet gates the PR| Workflow | Repo | Branch | Status | History | Duration | Finished | |
|---|---|---|---|---|---|---|---|
| Loading GitHub Actions runs… | |||||||
Framework suites
the framework itself: unit tests, cluster engines, app exposure, Dynatrace components — on the fleetLoading suites…
Recent Framework Runs
| Timestamp | Suite | Arch | Result | Duration | Log |
|---|---|---|---|---|---|
| — | |||||
Integration — per training repo
devcontainer CI: postCreate + integration.sh, on the fleet| Repository | Arch | Status | History | Duration | Finished |
|---|---|---|---|---|---|
| Loading nightly results… | |||||
Training end-to-end
the learner flow itself, via the Enablement App path — mint, provision, every step, terminate| Repository | Arch | Status | History | Duration | Finished |
|---|---|---|---|---|---|
| Loading nightly results… | |||||
Release use cases
GET /api/e2e/usecases — the release gate's use cases, their phases in declared order, and the command that runs eachReading the release use cases…
Runs
POST /api/e2e/runs queues one — GET /api/e2e/runs reads them back, newest first. The gate is executed by the runner, not by this service.Reading the release-gate runs…
Common failure patterns
Pipeline
Where each product's code has actually reached — and, per tenant, which bundle is installed.
Environments & tenants
installed app version per tenant — only for the pair this host holds a credential forOrbital deploys its own two tenants and no others. The other environment's tenants are listed because they exist, with their version marked not readable here — carrying a number across the boundary would be inventing it. A tenant that could not be reached and a tenant that answered without the app installed are different facts and render differently.
Release lanes
GET /api/deploy/drift — is anything on main that the channel has not taken?Who deployed what is under Register Tenant → Deploy activity, and every registered install is under Register Tenant → Tenant registry.
Environment health
GET /api/health on this host and, cross-origin, on its peer
The peer is read by your browser, not by Orbital — git is still the
only channel between the environments. Only /api/health is
obtainable across the boundary, so the peer card carries a status and its queue
depths and says plainly what it cannot show. Unreachable here and
unhealthy are different facts: the first means this host could not ask,
the second means the far side answered and reported itself ill. A card that
could not be read shows no counts at all, because a zero nobody measured reads
exactly like a zero somebody did.
Services
What systemd is running on this host — the units that deploy, schedule and reap.
A unit that is not installed here is an answer, not a fault: the two environments run different sets. Timers report their next firing and the outcome of the run they last fired; services report a pid and an uptime — neither shape borrows the other's empty columns. Journal tails are masked server-side.
| Unit | State | Since / next | Detail | Restarts | Last line | |
|---|---|---|---|---|---|---|
| Reading systemd… | ||||||
A profile is a named set of training repos. Map profiles to domains and tenants in the Tenants tab.
Loading profiles…
New / edit profile
Preview — what does a tenant receive?
Delivery table
Domain defaultsRegistered tenants, sorted by type. Registrant, name and plan come from the tenant registry; — means that tenant registered before we captured the field, or its OAuth client could not read it. A ● after a name means it was read from the account API rather than typed by the registrant.
| Tenant | Registrant | Name | Type | Plan | Profile |
|---|
Training sources Orbital delivers — WWSE Hands-On / Learning Bytes / SE Onboarding repos, and private repos for customer workshops. Adding a repo validates it on GitHub (with Orbital's token) before it's managed; reference it from a profile in the Profiles tab.
Add a training source
Managed training sources
| Repo | Branch | Type | Delivery |
|---|
Every workshop across every tenant. Click a row to edit or administer it. Creating workshops stays in the enablement app, where a trainer picks a training from their own tenant's catalogue.
Loading workshops…
All workshops
| When | Title | Trainer | Tenant | State | Seats | Registrants |
|---|
Only people on this list can schedule a workshop, and only they can turn on the tenant-wide solutions toggle. This is not the same as being an admin, and it grants nothing inside a workshop — authority there is workshop membership.
Add a trainer
Registered trainers
| Name | Added by | Added | Note | ||
|---|---|---|---|---|---|
| Loading trainers… | |||||
A notice shows as a banner on every page of the enablement app, for every signed-in user — learner, trainer and admin — on the tenants it targets. Post one at least 15 minutes before a restart or an update. It is readable by anyone, so never put an email, a name or a secret in it.
Post a notice
tools/post_notice.py release).Notices
Every notice ever posted, newest first — live and ended.
| Posted (UTC) | Severity | Title | Event (UTC) | Tenants | Served until (UTC) | By | State | |
|---|---|---|---|---|---|---|---|---|
| Loading notices… | ||||||||
Account OAuth client bootstrap install only
Paste it once. Nothing is stored here. Orbital uses the OAuth client to deploy the app, writes it into your tenant's own settings, and then discards it — it is never written to Orbital's disk, database or logs. From that moment the app is self-sufficient: it mints its own per-learner tokens and updates itself, on any tenant in any account, with no credential of yours living on this server.
How to create the OAuth client
In your tenant's account: myaccount.dynatrace.com → Identity & access management → OAuth clients → New. Add every scope below — the install is refused if any is missing, because a partly-scoped client produces an app that installs and then fails at runtime.
All 15 required scopes — 13 environment, 2 account
| Scope | Why it is needed |
|---|---|
| Environment | |
app-engine:apps:install | install and upgrade the app |
app-engine:apps:run | activate the installed version |
app-engine:apps:delete | uninstall — needed for the Undeploy button below |
app-settings:objects:read | check whether this tenant already has its Orbital token, so the install can tell you whether the manual step below is still outstanding. Optional — without it that check reports “could not verify” instead of a definite answer. |
settings:objects:read | read the outbound allowlist before changing it |
settings:objects:write | enable training-telemetry forwarding, add the hosts below to the outbound allowlist if your tenant enforces one, and — the important one — store this client in your own tenant so the app can mint and self-update without Orbital keeping anything |
environment-api:api-tokens:read | list and clean up the per-learner tokens the app minted |
environment-api:api-tokens:write | mint each learner's environment token directly (classic dt0c01) — the primary path, immune to per-user IAM differences |
environment-api:activegate-tokens:write | mint the ActiveGate token a Kubernetes lab environment needs |
document:documents:read | read training content stored on the tenant |
document:documents:write | import labs and images under one service identity — any admin can then manage them without creating duplicate copies |
document:documents:delete | remove labs the tenant's profile no longer lists |
document:documents:admin | manage content documents regardless of which admin imported them |
| Account | |
platform-token:tokens:write | mint per-user platform tokens where classic token creation has been retired (rolled out per environment) |
platform-token:tokens:manage | revoke them when a session ends |
Orbital checks the client against your tenant before installing anything and names any scope that is missing, so a wrong client costs you a message rather than a broken install. Want to verify first without installing anything? Run the tenant readiness check — same probes, nothing deployed. Note: scopes cannot be added to an existing client — if one is missing, create a new client.
After install, and the outbound allowlist
After install: nothing, if the client is complete
The install writes the client into your tenant's own Settings → Training Token Minting and the app takes it from there — per-learner tokens, and its own updates. The deploy result says stored when that worked; if it says anything else it also says which permission is missing, and you can paste the same client on that Settings page by hand.
Why the app must mint at all: creating classic API tokens is being retired per environment, so a tenant that mints them happily today can stop tomorrow while a sibling tenant in the same account carries on. A client with the two platform-token account permissions is what makes that transition a non-event.
Outbound allowlist (if your tenant enforces it)
These hosts are added to your app-function allowlist during install:
Every deploy, upgrade, undeploy and preflight refusal, newest first. Filters apply to the rows already fetched — raise the row count to widen the window.
| When | User | Tenant | Stage | Action | Result | Version | Via |
|---|---|---|---|---|---|---|---|
| Loading… | |||||||
Attribution registry — who deployed where. One row per registered install; org members only. Recorded at deploy is what Orbital wrote when it last deployed the tenant; installed now is a live probe, scoped to the tenants this host holds a credential for, so most rows read not probed here. When both are known and differ, the deploy did not land. Deployed by is who triggered the last deploy (often not a person); administered by is the tenant's contact address — neither fills the other, and a field never captured reads not recorded. Filters apply to the whole registry, which is read in full.
| Tenant | Name | Audience | Recorded at deploy | Installed now | Last deploy | Via | Deployed by | Administered by | Account |
|---|---|---|---|---|---|---|---|---|---|
| Loading… | |||||||||
Loading settings…