internal active Last verified 2026-03-29

Deployments And Observability

Operational guidance for finding the serving surface, deployment path, and runtime ownership of platform changes.

Owners
platform
Source Repos
Applications/TopoloAuth, Applications/TopoloOne
Systems
Topolo Auth, TopoloOne, Topolo Platform
Tags
operations, deployments, observability

What It Is

This page records the operational entrypoints for verifying what is actually serving traffic and which system owns a live behavior change.

How It Works

Most platform-level operator flows span at least one UI deployment and one Auth-backed service. Debugging starts by identifying the served hostname and matching it to the live worker or Pages project.

Interfaces

  • Cloudflare Workers and Pages deployment surfaces
  • application hostnames
  • Auth routes and UI bundle endpoints

Data Flow

  1. A user action hits the served UI hostname.
  2. The UI bundle calls Auth or an application service.
  3. The service reads backing data stores and returns the result.
  4. Operators validate the runtime route, not just the repo state.

Failure Modes

  • the hostname points at an older deployment surface
  • a worker asset or route shadows the intended Pages build
  • the UI bundle is current but the backing Auth data is stale
  • the app is correct but the docs or registry still reference the wrong surface

Debugging

  • confirm the live hostname and served bundle name
  • confirm the worker or Pages route currently attached to the hostname
  • confirm the backing Auth endpoints respond with the expected catalog data
  • use the service registry and system handbooks before assuming a frontend-only issue

Change Log / Verification

  • Established as the platform operations baseline on 2026-03-29