SphereOps

SphereOps is the console-wide operations dashboard. Instead of clicking into each service to read its metrics or logs, SphereOps lets you scope a single view across one or many services, in one or many environments, for a time range you choose.

Use it when you want to look across a slice of your account — a whole project during a deploy, every service in production during an incident, or one service across the last hour vs the last day.

What's on the dashboard

Surface	What it shows
Monitoring type	Metrics, runtime logs, build logs, or deploy logs. Pick one per view.
Environment scope	One or more environments. Cross-environment views are read-only — services in different environments aren't network-connected (see Environments don't cross-talk).
Service scope	One or more services in the selected environments.
Time range	Predefined windows (last 15 minutes, last hour, last 24 hours, last 7 days) or a custom range.

The dashboard renders charts and log streams based on the selected combination. Each chart can be customized — line, bar, or heatmap depending on the metric.

Open SphereOps

1. Log in to the console and click SphereOps in the left navigation.
2. The first time you open it, the personalization form lets you pick which metrics matter to you — CPU, memory, request rate, error rate, etc. These become your default visualizations.
3. Pick a monitoring type, the environment(s), the service(s), and the time range. The dashboard refreshes as you change selections.

To add a new visualization later, click Add visualization on the dashboard and pick the metric + chart type.

Reading the views

View	What you see
Metrics	Time-series charts for CPU, memory, spherelet count, storage usage, and request-side metrics where applicable.
Runtime logs	The application logs your service writes to stdout/stderr at runtime, across the selected services and time range.
Build logs	Output from the source-to-image build, when the service is connected to a Git repo.
Deploy logs	The rollout's progress — health-check results, traffic-switch events, drain confirmations.

API access

The console SphereOps view is a UI convenience over per-deployment endpoints. The API itself doesn't have a /sphereops aggregator — to pull the same data programmatically, query each deployment directly:

Data	Endpoint
Metrics	GET /v2/deployments/:id/metrics
Runtime logs (history)	GET /v2/deployments/:id/logs/runtime
Runtime log histogram	GET /v2/deployments/:id/logs/runtime/histogram
Runtime log stream (SSE)	GET /v2/deployments/:id/logs/runtime/stream (requires a stream token from /logs/runtime/stream/token)
Build logs	GET /v2/deployments/:id/logs/build/:deployId
Deploy logs	GET /v2/deployments/:id/logs/deploy

All require Authorization: Bearer YOUR_API_TOKEN and x-account-id for multi-account disambiguation. See API keys for the token-issuance flow and the API reference for full request/response shapes.

Honest limits

• No cross-region SphereOps. Services in different regions can't be co-charted; the dashboard scopes implicitly to your account's region (regions are set at the account level — see Architecture → Regions).
• The visualization config is per-account, per-user. Two users in the same account can have different default visualizations. There's no shared dashboard configuration today.
• No alerting from SphereOps. Alerts on metrics are configured separately — see Alerts.
• No metrics export from this dashboard. If you need raw metrics in your own observability stack, query the per-deployment endpoints above and write the integration yourself.
• Build logs require a Git-connected service. Services deployed from a container image don't go through the build system, so the build-logs view shows nothing for them.

What's next

• Logs — log retention, what's captured, how runtime/build/deploy logs differ.
• Alerts — turn an interesting SphereOps pattern into a paging alert.
• Auto-scaling — drive scaling decisions from the same metrics SphereOps surfaces.
• Service actions — what each rollout in the deploy-logs view is actually doing.