What You Can Do vs. What We Manage

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.

If something is not listed here, ask in your support channel 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 below)

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

The boundary, layer by layer

Layer	CTO2B manages	You manage
Kubernetes	Cluster provisioning, upgrades, node health, platform namespaces	Your application manifests, resource requests and limits
Deployments	The GitOps tooling and its operation	Your Helm values, image tags, and Git repository
Databases	The instance, engine version and patching, automated backups, network connectivity	Schema design, query performance, data migrations
Ingress and networking	Ingress controller, load balancer, TLS certificates	Your domain DNS records and your ingress routing rules
Observability	Platform-level monitoring; provisioning an optional stack for your team	Interpreting your own metrics, your own dashboards and alert thresholds
Security	Platform RBAC, standard network policies, access tooling	Your application's own authentication and authorisation
CI/CD	Everything from the container registry onward	Everything up to the image push: code, build, pipeline configuration

Boundary examples

Pods evicted under memory pressure — check your own resource requests and
limits before raising a request.
A deployment fails to sync after your own change — the manifests, Helm
values, and image tags are yours. Your Customer Success Engineer can advise,
but will not edit your repository.
Slow queries or missing indexes — application-layer, and yours. If
database response times degrade because of infrastructure limits such as
storage or I/O, CTO2B investigates.
Your application URL does not resolve — check that your DNS record points
at the correct load balancer address first. Domain ownership and your DNS or
proxy provider account remain yours.

Observability

CTO2B deploys a monitoring stack on every cluster for its own operational use.
That stack is not visible to your team, and its alerts route to CTO2B, not to
you.

If your team wants its own Grafana dashboards, metrics, and logs with admin
access, you can request a dedicated observability stack. It is opt-in and
provisioned on request. Once you have it, building dashboards, setting alert
thresholds, and routing your own alerts are yours to manage. See
Observability.

For the same boundary with the specific technologies named — EKS, ArgoCD, RDS, Traefik, the observability stack — see The Boundary in Detail.

Not yet self-service

Raise a request for anything in this list.

Infrastructure

Creating new Environments or namespaces — include the environment name,
cloud provider, and stage
New Kafka topics or users — see Access Management

Cloud console access

AWS IAM users — for CI/CD pipelines, external SaaS, or other third-party
integrations; see AWS S3 and IAM Access
AWS S3 bucket policies — cross-account or cross-service access beyond what
the Catalog provisions; see AWS S3 and IAM Access
IAM Service Accounts — for third-party integrations or Workload Identity;
see GCP IAM and GCS Access
GCP cross-project IAM permissions — see GCP IAM and GCS Access
DNS configuration — pointing a custom domain at the PushOps load balancer

Networking

CloudFlare traffic shielding — restricting your load balancer to accept
traffic only via CloudFlare; requires CloudFlare Proxy active on your domain;
see Ingress, Custom Domains and TLS
Cross-namespace network policies — see Network Policies
Egress restriction — locking outbound traffic to specific external
endpoints for compliance; see Network Policies

Access and roles

Role changes — a different SVIEW role or additional permissions; see
User Profile

Compliance

Audit evidence packages — platform-level evidence for SOC 2, DORA, or
other audits; see Audit Logs, SOC 2 Compliance on the PushOps Platform, Digital Operational Resilience Act (DORA)

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 — raise Sev-1 or Sev-2
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 — raise Sev-2
My URL returns 503	Check your deployment and DNS first; if platform ingress is at fault, raise Sev-2
Database unreachable from my application	CTO2B — raise Sev-2
Slow database queries	You — check your queries and indexes
I want a custom Grafana dashboard	Professional Services
Grafana access for a new team member	Raise a Sev-3 request

Key Concepts — the vocabulary used above
Observability — requesting your own monitoring stack
Getting Help — how to raise a request and how severity is assigned