What You Can Do vs. What We Manage
Which parts of PushOps your team manages in SVIEW, which CTO2B manages for you, what needs Professional Services, and who acts first.
PushOps splits responsibility between what your team manages directly in SVIEW
and what CTO2B manages on your behalf. The rule of thumb is that CTO2B owns the
infrastructure layer and your team owns the application and its configuration.
This page is the short version. For the boundary layer by layer, with the
specific technologies named and what is not yet self-service, see
The Boundary in Detail. If something is not listed in
either, raise a request and we will point you in the right direction.
What you can do in SVIEW
| Area | What you can do |
|---|---|
| Databases and data services | Provision PostgreSQL, MySQL, Redis, Kafka, and other services from the Catalog |
| Container registry | Configure your ECR / GCR registry |
| Environment variables and secrets | Manage variables and secrets for your Components |
| Resource limits and deployment parameters | Adjust these per Component |
| Networking | Manage ingress routes and IP allowlisting |
| Node provisioning (AWS) | Adjust Karpenter node pool settings |
| Access | Raise and approve infrastructure access requests |
| Visibility | View audit logs, cost reports, compliance reports, and service health |
| Application logs | View and search Component logs in the Application view (recent window, up to 6 hours) |
| Observability | Request your own dedicated monitoring stack — see Observability |
What CTO2B manages
| Area | Description |
|---|---|
| Kubernetes control plane | Cluster provisioning, upgrades, and node health (EKS / GKE) |
| Deployment orchestration | The GitOps layer that deploys your workloads |
| Infrastructure provisioning | The underlying cloud infrastructure, managed as code |
| Cloud foundation | Core AWS / GCP account infrastructure |
| Platform monitoring | CTO2B's own monitoring of platform health, for CTO2B operational use |
| Security components | Certificate issuance and renewal, secrets management, standard network policies |
What requires Professional Services
The following sit outside standard PushOps support and need a separate
Professional Services engagement:
- Custom dashboard or alert rule development
- Application performance optimisation and profiling
- Database query tuning or schema redesign
- CI/CD pipeline design or migration, once onboarding has completed
- Application architecture review
Speak to your Customer Success Engineer to scope one.
Quick reference: is this ours or yours?
Severity levels are defined in the SLA Policy — Sev-1 (critical), Sev-2 (degraded), Sev-3 (non-urgent).
| Situation | Who acts first |
|---|---|
| Cluster node is NotReady | CTO2B — open a Sev-1 or Sev-2 support request |
| My pod is in CrashLoopBackOff | You — check your application logs |
| Deployment out of sync after my commit | You — check your manifests |
| Deployment out of sync, nothing changed | CTO2B — open a Sev-2 support request |
| My URL returns 503 | Check your deployment and DNS first; if platform ingress is at fault, open a Sev-2 support request |
| Database unreachable from my application | CTO2B — open a Sev-2 support request |
| Slow database queries | You — check your queries and indexes |
| I want a custom Grafana dashboard | Professional Services |
| Grafana access for a new team member | Open a Sev-3 support request |
Related articles
- The Boundary in Detail — layer by layer, and what is not yet self-service
- Key Concepts — the vocabulary used above
- Why Changes Made in the Cloud Console or with kubectl Are Reverted — why changes belong in SVIEW
- Getting Help — how to raise a request and how severity is assigned
Updated about 1 month ago