Gateway Ops

Gateway Ops is the administrator console for the Cloud gateway and shared operational signals. It connects application registration and route ownership with request telemetry, logs, background work, storage diagnostics, and alert delivery.

Use Gateway Ops

• Check which application instances are online, stale, degraded, or offline.
• Confirm which application owns a route prefix and inspect its traffic and error counters.
• Start an incident investigation from the overview, then narrow it with telemetry, logs, jobs, or workflows.
• Inspect bounded Postgres and Valkey diagnostics when evidence points to storage pressure or stale data.
• Review notification delivery and configure health webhooks for operator alerts.

Gateway Ops requires administrator access. Removing an offline registration cleans the gateway registry; it does not restart or repair the application.

In Logs, Jobs, Notifications, Postgres, and Redis, Clear resets active filters on desktop and mobile. Notification filters reset within the currently selected view; Jobs keeps the selected source. Telemetry clears its filters while keeping the time range. Search and filter links preserve the other selections and reset pagination when the result set changes.

Tables use consistent headings, controls, pagination, and labeled status badges. A failed log query shows an error rather than an empty result. Job runs and events include their time of day. Logs, job details and timelines, request details, and gateway timestamps use your configured time zone; charts explicitly labeled UTC retain UTC.

Gateway traffic counts and server telemetry percentages follow your language's number formatting. Gateway error percentages use whole numbers; telemetry error percentages retain one decimal place.

Understand the Gateway Ops model

Health webhooks allow public targets by default and never follow redirects; the operator can allow internal hosts with GATEWAY_OPS_WEBHOOK_ALLOWED_TARGETS in the Gateway Ops container (an explicit value replaces the empty default).

Postgres shows sequential and index scan counts for each table, deadlocks, and the age of the oldest transaction and active query. Scan and deadlock counts accumulate since the corresponding statistics were reset; a sequential scan alone does not imply a missing index. Sessions, indexes, and tables appear before storage charts.

Postgres and Valkey use consistent diagnostic notices: an amber tint for warnings and a red tint for critical findings. Each notice names the problem in its title.

Postgres row counts are planner estimates. Valkey prefixes come from a bounded sample rather than a raw key browser. Use these views to direct an investigation, not as exact replacements for database administration tools.

PostgreSQL connection counts and limits describe the database server, including connections to other databases on that server. They do not report PgBouncer clients, pool limits, or time spent waiting for a pool connection. A pool can be full while PostgreSQL still has free connections. With transaction pooling, sessions describe shared PostgreSQL backends rather than persistent application connections. Monitor PgBouncer separately for pool pressure.

Session and index panels report failed queries as unavailable, so a loading failure is not mistaken for an empty database. The corresponding administrator API endpoints return an error instead of a successful empty list.

How Gateway Ops fits Cloud

The gateway owns registry-driven routing. Gateway Ops owns the administrator views and maintenance actions around that runtime state. Applications still own their health implementation, logs, domain failures, and recovery. Cloud supplies the shared logging, telemetry, jobs, workflows, notifications, and settings contracts displayed here.

Find detailed product help

Open Help inside Gateway Ops for the normal diagnosis path, health states, webhook behavior, operational fields, and safe recovery steps. Developers can read Observability, Application lifecycle, and Runtime configuration for the contracts behind these signals.

Inspect Gateway Ops from the terminal

Gateway operations are part of the shared administrator module rather than a separate cld gateway module. Start with health and active route ownership:

cld admin status --json
cld admin routes list --errors --json

Run cld admin help for logs, telemetry, jobs, workflows, notifications, and bounded storage diagnostics. Run cld admin <area> <command> --help before a maintenance action.

Deployment requirements

See Deployment requirements for this app’s startup prerequisites, optional integrations, configuration and functional checks.