# Prometheus
All Prometheus notes →2 — Security
Securing the exporter-to-Prometheus link with TLS and basic auth — self-signed certs, bcrypt password hashing, tls_server_config, and end-to-end curl verification, plus an honest look at what this setup doesn't cover.
1 — Kubernetes Best Practices
Running Prometheus on Kubernetes via Helm and the Prometheus Operator's kube-prometheus-stack — RBAC scope, TLS between components, and NetworkPolicy isolation for the monitoring namespace.
3 — Troubleshooting
Diagnosing missing metrics, duplicate series, high-cardinality blowups, slow queries, WAL corruption, and memory pressure/OOMKills in a running Prometheus deployment.
# Projects
All Projects notes →Known issues
Recurring limitations and accepted trade-offs across Signal Forge, consolidated in one place to check before assuming a gap is new.
Networking & TLS
Network-plane security for Signal Forge: NetworkPolicy default-deny model, Ingress TLS via cert-manager, and the k3d flannel enforcement caveat.
Reliability controls
Workload-level Kubernetes controls protecting Signal Forge availability during disruption: PodDisruptionBudgets, anti-affinity, and graceful shutdown.
Resilience patterns
Application-level failure handling in Signal Forge: retries, circuit breakers, backoff, and delivery-safety patterns for downstream dependency failures.
Runbooks
Troubleshooting playbooks for every known Signal Forge failure mode, from missing traces to Grafana Cloud export errors.
Security
Threat model and secrets lifecycle reference for Signal Forge, covering credential management, input validation, CORS, RBAC, and rotation procedures.
Supply-chain security
What CI verifies before a Signal Forge image ships: vulnerability scanning, SBOM generation, and cosign keyless signing.
Alert Runbooks
Runbooks invoked directly from paging alerts.
Runbook — ShipSolidApiGateway5xxHigh
- **Service:** api-gateway - **Owner Team:** Platform SRE
Communication Templates
Copy-paste communication templates for incidents.
Incident Response Playbook
The step-by-step incident response flow for platform-impacting incidents.
Incident Trends & Themes
Cross-incident analysis — recurring themes, top contributors, and where to invest.
On-Call Handbook
Everything an on-call engineer needs for a shift on the observability platform.
04 — Operations & Incident Response
Running the platform: on-call, incident response, runbooks, and post-mortems.
2026-05-21 — billing-service elevated latency
- **Incident Commander:** On-call Engineer (Platform SRE)
Post-Mortems
Blameless post-mortems for resolved incidents.
Rotation Schedule
Current on-call rotation and schedule.
Runbook Index
Index of all operational runbooks.
Severity Definitions
Severity definitions so everyone agrees on what SEV-n means.
Incident Notification & Response
**Owner:** SRE Team **Last Updated:** 2025-05-01 **Applies to:** All production alerts routed
Notification & Alerting Strategy
A unified approach to delivering actionable alerts, minimizing noise, and ensuring timely
SRE Toolkit
The `srekit` CLI is a Python-based toolkit for SRE operations, located in
Visualization, Alerting & SLOs
An effective observability system translates raw telemetry into actionable insights through
# Internal Developer Platforms
All Internal Developer Platforms notes →1 — Platform Operations
Day-two operational responsibilities for running the platform itself as a production system.
2 — Platform Reliability
Reliability engineering applied to the platform's own control plane: the platform going down blocks every team behind it, not just one service.
3 — Platform Observability
Observability requirements for the platform's own control plane and workflows, distinct from the observability the platform provides to its tenants.
4 — Platform Support Models
Support models for a platform team, from ticket queues to embedded support to fully self-service, and when each is appropriate.
5 — Incident Management
Incident management specific to platform outages, where the blast radius is every consuming team rather than a single service's users.
6 — Platform Evolution
How a platform evolves after initial adoption: deprecating capabilities, migrating tenants, and avoiding a permanent legacy tax.