Technical enablement · 04

Operations & administration

What the team that runs {{product.name}} needs: managing tenants and access, monitoring health, tracking cost, triaging incidents and following runbooks. These are operator-facing capabilities, not customer features.

❗

Operator-only. Administrative functions can see across tenants. Gate them behind a separate role, audit every action, and never expose them to customers. [Replace: the role name and how it is granted.]

Tenancy & access management

How tenants, users and roles are created and changed. Document the supported route (admin UI, API or script) and who is allowed to use it.

Task	How	Who	Audited
Create a tenant	[Replace: admin UI / API call]	Platform admin	Yes
Create first tenant admin	[Replace: invite flow]	Platform admin	Yes
Change a user's role	[Replace]	Tenant admin	Yes
Suspend or offboard a tenant	[Replace: data-retention steps]	Platform admin, with approval	Yes
Break-glass access to a tenant	[Replace: time-boxed, ticket-linked]	[Replace: named role]	Yes, reviewed

Example: create a tenant (replace with the real call)

curl -X POST "$API_BASE/admin/tenants" \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name": "[tenant-name]", "plan": "[plan]", "adminEmail": "[admin@example.com]"}'

Monitoring & alerts

Define the signals that tell you the product is healthy, who is paged and where the dashboards live.

Signal	Threshold	Severity	Action
API availability	[Replace: e.g. < 99.5% over 5 min]	High	Page on-call; follow runbook RB-01.
Error rate (5xx)	[Replace]	High	Check recent deploys; roll back if correlated.
Latency p95	[Replace]	Medium	Inspect traces for the slow dependency.
Background-job lag	[Replace]	Medium	Scale workers; check dead-letter queue.
Data freshness	[Replace]	Medium	Inspect the ingestion pipeline.
Certificate / secret expiry	30 days before	Low	Rotate per policy.

Dashboards: [Replace: links]. On-call rota: [Replace: link]. Status page: [Replace: link or n/a].

Scheduled jobs & data operations

Job	Schedule	Safe to re-run?	Owner
[Replace: ingestion sync]	[Replace: cron]	Yes (idempotent)	[Replace]
[Replace: nightly aggregation]	[Replace]	Yes	[Replace]
[Replace: retention purge]	[Replace]	No — confirm scope first	[Replace]

⚠

Destructive jobs (purges, re-keying, bulk deletes) need a second approver and a verified backup. Record the procedure here, not only in a chat thread.

Cost & usage

Make unit cost visible per tenant so pricing and capacity decisions rest on data. Agree reporting with Finance; this page documents the technical mechanism only.

Cost driver	Metered by	Report	Control
Compute & storage	Cloud tags per tenant or environment	[Replace: cost dashboard]	Right-sizing, autoscaling limits
AI model usage	Token counts per tenant and feature	[Replace]	Per-tenant budgets, cheaper model tiers, caching
Third-party licences / APIs	Usage exports	[Replace]	Quotas, contract review
Support effort	Ticket volume per tenant	[Replace]	Self-service, documentation

Support & error triage

A consistent path from "something is wrong" to a fix.

Intake and classify

Capture tenant, time, correlation id and impact. Classify severity (S1 to S4) using [Replace: severity matrix link].
Diagnose

Use the correlation id to pull logs and traces; check recent deployments and feature-flag changes; check third-party status pages.
Mitigate and communicate

Apply the runbook mitigation (rollback, flag off, scale up). Update the status channel at the cadence the severity requires.
Resolve and review

Confirm recovery, record the root cause and follow-up actions, and update the runbook if it was missing or wrong.

Severity	Definition	Response target	Update cadence
S1	Service down or data at risk for many tenants	[Replace]	[Replace]
S2	Major feature degraded	[Replace]	[Replace]
S3	Minor issue with workaround	[Replace]	[Replace]
S4	Question or cosmetic issue	[Replace]	[Replace]

Support channel: {{links.support}} · Contact: {{product.contactEmail}}

Feature flags & configuration

List the flags operators can change at runtime, their default and the blast radius of flipping them.

Flag	Default	Scope	Effect
`[REPLACE_FLAG_NAME]`	off	Per tenant	[Replace: what turns on]
`[REPLACE_FLAG_NAME]`	on	Global	[Replace]

Runbook scaffold

Copy this block for each recurring operational task or alert. A good runbook can be followed by someone who did not write it, at 03:00.

Runbook template

RB-XX  [Title: the alert or task]
Owner:        [team / on-call rota]
Last tested:  [date]
Trigger:      [alert name or situation]
Impact:       [who/what is affected]

1. Verify      - [dashboard / command that confirms the problem]
2. Mitigate    - [safest first action: rollback, flag off, scale up]
3. Diagnose    - [logs, traces, queries to run; expected output]
4. Fix         - [procedure; who must approve]
5. Verify fix  - [how to confirm recovery]
6. Escalate    - [who, when, how]
7. Follow-up   - [post-incident review; update this runbook]

ID	Runbook	Trigger	Link
RB-01	[Replace: API unavailable]	Availability alert	[Replace]
RB-02	[Replace: Ingestion backlog]	Job-lag alert	[Replace]
RB-03	[Replace: Rotate secrets]	Scheduled	[Replace]

ⓘ

Related: non-functional targets and deployment models, which change who is responsible for each task here.