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
- Log in to the console and click SphereOps in the left navigation.
- 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.
- 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 /api/v2/deployments/:id/metrics |
| Runtime logs (history) | GET /api/v2/deployments/:id/logs/runtime |
| Runtime log histogram | GET /api/v2/deployments/:id/logs/runtime/histogram |
| Runtime log stream (SSE) | GET /api/v2/deployments/:id/logs/runtime/stream (requires a stream token from /logs/runtime/stream/token) |
| Build logs | GET /api/v2/deployments/:id/logs/build/:deployId |
| Deploy logs | GET /api/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.