
I was deep into a refactor. Claude Code had been solid for the first hour — renaming modules, updating imports, rewriting tests. Clean work. Then it started suggesting imports from files that didn't exist.

Not typos. Fully invented module paths. Confident syntax pointing at nothing.

I didn't catch it immediately. The code looked right. The structure made sense. But the files it was referencing? Never existed. I burned 20 minutes debugging phantom imports before I realized what was happening.

The context window was full.

## The Problem Nobody Warns You About

Claude Code has a finite context window. Every message you send, every file it reads, every diff it generates — all of it accumulates. When that window approaches capacity, the model starts compressing older context. Details get fuzzy. Specifics get replaced with plausible-sounding guesses.

And here's the dangerous part: **it doesn't look wrong**. The code still has correct syntax. Variable names still follow your conventions. The structure still matches your project. But the actual content — file paths, function signatures, import locations — starts drifting from reality.

I've seen it:

- **Hallucinated imports** — referencing modules that don't exist, with paths that look plausible
- **Phantom files** — trying to edit files it read 40 messages ago, using outdated content
- **Mixed-up logic** — combining patterns from different parts of the codebase into something that compiles but does the wrong thing
- **Confident nonsense** — generating entire blocks of code that reference APIs or configs from earlier context that have since been compressed away

The worst part? There's no warning. No error. No "hey, I'm running low on context." It just quietly degrades.

## The Fix: Make Context Visible

The solution was embarrassingly simple. I needed to see the context usage — not buried in some debug menu, but right there in the terminal, updating in real-time.

Claude Code supports custom statuslines. A shell script that receives session data as JSON on stdin and prints whatever you want to the bottom of the terminal. I wrote one that shows a progress bar for context usage.

Now my terminal looks like this:

```
[Opus] my-project
[####------] 42% | $0.85 | 12m 34s
```

That progress bar changed everything.

## What Changed

With context usage always visible, I developed a simple habit: **when context hits ~70%, start a new session**.

Not 90%. Not 80%. 70%.

Why that early? Because degradation doesn't start at 100%. By the time the window is full, the model has already been compressing and losing detail for a while. At 70%, the quality is still solid but you're on borrowed time. Starting fresh with a `/compact` or a new session at that point means you never enter the danger zone.

Before the statusline, my workflow looked like this:

1. Start a session
2. Work for an hour
3. Notice weird output
4. Debug the weird output
5. Realize the context is full
6. Start over, having wasted 20 minutes

Now:

1. Start a session
2. Work while glancing at the bar
3. See it hit 70%
4. Start a new session
5. Keep going without interruption

The difference in wasted time is massive.

## How Statuslines Work

Claude Code pipes a JSON object to your script's stdin on every update:

```json
{
  "model": { "display_name": "Opus" },
  "workspace": { "current_dir": "/home/user/my-project" },
  "cost": {
    "total_cost_usd": 0.85,
    "total_duration_ms": 754000,
    "total_lines_added": 156,
    "total_lines_removed": 23
  },
  "context_window": {
    "used_percentage": 42,
    "total_input_tokens": 84000,
    "total_output_tokens": 12500
  },
  "version": "1.0.80"
}
```

Your script reads it, extracts what matters with `jq`, and prints formatted output. That's the entire contract.

Here's the context-focused script I started with:

```bash
#!/bin/bash
input=$(cat)

model=$(echo "$input" | jq -r '.model.display_name // "unknown"')
ctx=$(echo "$input" | jq -r '.context_window.used_percentage // 0')

# Progress bar
bar_width=10
filled=$((ctx * bar_width / 100))
empty=$((bar_width - filled))
bar=$(printf "%${filled}s" | tr " " "#")$(printf "%${empty}s" | tr " " "-")

# Color: green under 60, yellow 60-80, red above 80
if [ "$ctx" -ge 80 ]; then
  CLR="\033[31m"
elif [ "$ctx" -ge 60 ]; then
  CLR="\033[33m"
else
  CLR="\033[32m"
fi
RST="\033[0m"

echo -e "[${model}] ${CLR}[${bar}] ${ctx}%${RST}"
```

Green when you're safe. Yellow when you should wrap up. Red when you need to stop and start fresh. You can't miss it.

## Setting It Up

Three steps:

1. Save the script to `~/.claude/statusline.sh`
2. Run `chmod +x ~/.claude/statusline.sh`
3. Add to `~/.claude/settings.json`:

```json
{
  "statusLine": {
    "type": "command",
    "command": "~/.claude/statusline.sh"
  }
}
```

Note: the key is `statusLine` (camelCase), not `statusline`. Restart Claude Code and the bar appears.

## I Built a Tool So You Don't Have to Write Bash

After setting up my own statusline, I realized most people aren't going to hand-write bash scripts with ANSI escape codes for a status bar. So I built a [Statusline Builder](/tools/statusline).

Pick a template, toggle the segments you want, choose a color theme, and copy the script. The live preview shows exactly what it'll look like. 30 seconds, no bash knowledge required.

The builder has five presets:

- **Minimal** — just the model and context percentage
- **Standard** — model, directory, context, and cost
- **Rich** — two lines with a progress bar, cost, and duration
- **DevOps** — context plus lines added/removed
- **Colorful** — color-coded bar with threshold warnings

You can also mix and match 11 different segments: model, directory, context bar, cost, duration, lines changed, tokens, version.

## The Real Lesson

The context window is the single most important resource in a Claude Code session. More important than the model. More important than the prompt. When it runs out, everything degrades — silently.

You wouldn't run a production system without monitoring memory usage. Don't run Claude Code without monitoring context usage.

A progress bar at the bottom of the terminal is all it takes. It's the cheapest insurance you'll ever set up.

[Build yours here.](/tools/statusline)


When Claude Code's context window fills up, output quality tanks — hallucinated imports, phantom files, broken logic. I fixed it by adding a statusline that shows context usage in real-time, and built a tool so you can do the same.

Claude Code Was Hallucinating. The Fix Was a Progress Bar.


At first glance, everything looked fine.

Dashboards were green. Pods were running. CPU usage was low. Memory was stable. No crashes. No restarts. No alerts.

And yet, production felt broken.

This isn't a war story from a production outage. This is something I built on purpose.

I work with on-prem systems day to day, so I keep a small Kubernetes lab running to stay sharp. Not for tutorials. Not for certifications. For reproducing the kind of production pain that metrics don't show.

## The Scenario I Built on Purpose

The goal was simple:

- Increase latency
- Keep CPU low
- Avoid errors
- Avoid crashes
- Keep every pod in `Running` state

I wanted to create pain without pressure.

The service would sometimes respond in milliseconds, sometimes in seconds. No pattern. No warning. From the user's perspective, the system felt unreliable. From Kubernetes' perspective, everything was perfectly fine.

## The First Things I Checked

Like most people, I started with the basics:

```bash
kubectl get pods
kubectl top pods
```

What I saw looked reassuring — CPU was low, memory usage was low, all pods were running, replica counts were stable.

My conclusion was quick. And wrong.

*"The cluster is healthy."*

That was my first mistake.

## Why CPU Fooled Me

The latency I introduced had nothing to do with CPU. No heavy computation. No resource exhaustion. No obvious bottleneck. Just waiting. Blocking. Slow responses.

From Kubernetes' point of view, there was nothing to react to:

- No CPU pressure
- No memory pressure
- No reason to intervene

The cluster wasn't lying to me. It was answering exactly the question I was asking.

## The Second Illusion: Multiple Replicas

I also had more than one replica running. That should have helped, right?

I assumed traffic would naturally balance out and the system would feel stable. What actually happened:

- Some pods were fast
- Some pods were slow
- Requests randomly landed on the slow ones

The averages looked fine. User experience did not. Nothing was technically "down", but nothing felt reliable either.

## What the Real Problem Was

It wasn't CPU. It wasn't memory. It wasn't pod health.

The real issue was **time**.

- Latency variance
- Tail latency
- Unpredictable response times

None of these showed up in the metrics I was watching.

## The Core Lesson

Kubernetes optimizes for **resource pressure**. Users experience **time**.

A green cluster does not guarantee a healthy production experience.

## What I Took Away

- **"Running" does not mean "working well"** — a pod can be in Running state and still serve terrible responses
- **Low CPU does not mean good user experience** — latency problems don't need compute pressure
- **Averages hide real pain** — P50 can look great while P99 is destroying the experience
- **Latency is a first-class signal** — it belongs on your primary dashboard, not buried in traces
- **Looking healthy is not the same as being healthy** — this applies to clusters and to observability strategies

## What Comes Next

The fix didn't involve refactoring the slow service. No performance tuning. No "just scale it."

Only platform decisions: readiness probes, traffic isolation, and understanding that protecting users is not the same thing as fixing latency.

Once you stop trusting green dashboards, that's when the real work starts.


Green dashboards, running pods, low CPU — and yet production felt broken. A story about why Kubernetes metrics can lie about user experience, and what to watch instead.

My Kubernetes Cluster Looked Healthy. Production Wasn't.


Manually updating container image tags after every CI build defeats the purpose of continuous deployment. I built a fully automated GitOps pipeline on GKE using ArgoCD Image Updater that closes the loop between pushing code and deploying it — no human intervention required.

This post walks through the architecture, the key configuration decisions, and what I learned.

## What the Pipeline Does

The flow is straightforward:

1. Code gets pushed to `main`
2. GitHub Actions builds the Docker image, tags it with SemVer (`1.0.{run_number}`), and pushes to Google Artifact Registry
3. ArgoCD Image Updater detects the new tag in the registry
4. Image Updater writes the updated tag back to Git
5. ArgoCD syncs the change to the cluster
6. Slack gets notified

No one touches `kubectl`. No one edits a values file. The whole thing runs on its own.

## Git Folder Structure

The repo manages multiple environments and namespaces, with Helm charts handling the templating:

```
nodejs-express-mysql/
├── Dockerfile
├── deploy/
│   ├── dev/
│   │   └── values-dev.yaml
│   ├── prod/
│   │   └── values-prod.yaml
│   └── helm/
│       ├── Chart.yaml
│       ├── templates/
│       └── values.yaml
```

Each environment gets its own `values-{env}.yaml` with specific replica counts, resource limits, and autoscaling thresholds. The Helm chart stays generic — the values files are where environments diverge.

## GitHub Actions: Build and Push

The CI workflow triggers on every push to `main`, builds the image, and pushes to Artifact Registry with a semantic version tag:

```yaml
name: Build and Push Docker Image
on:
  push:
    branches: [main]
jobs:
  build:
    if: github.actor != 'argocd-image-updater'
    runs-on: ubuntu-latest
    env:
      IMAGE_TAG: 1.0.${{ github.run_number }}
    steps:
      - uses: actions/checkout@v3
      - uses: google-github-actions/auth@v1
        with:
          credentials_json: ${{ secrets.GCP_SERVICE_ACCOUNT_KEY }}
      - run: gcloud auth configure-docker europe-west1-docker.pkg.dev
      - run: |
          docker build -t europe-west1-docker.pkg.dev/project/repo/app:${{ env.IMAGE_TAG }} .
          docker push europe-west1-docker.pkg.dev/project/repo/app:${{ env.IMAGE_TAG }}
```

The `if: github.actor != 'argocd-image-updater'` guard is important — without it, the Image Updater's write-back commits would trigger infinite build loops.

## ArgoCD Image Updater Configuration

The Image Updater needs to authenticate with Google Artifact Registry. I used a ConfigMap with an authentication script that retrieves an OAuth2 token from the GKE node's metadata server:

```yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: auth-cm
  namespace: argocd
data:
  auth.sh: |
    #!/bin/sh
    ACCESS_TOKEN=$(wget --header 'Metadata-Flavor: Google' \
      http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token \
      -q -O - | grep -Eo '"access_token":.*?[^\\]",' | cut -d '"' -f 4)
    echo "oauth2accesstoken:$ACCESS_TOKEN"
```

The Image Updater config references this script with a 30-minute credential expiration:

```yaml
registries:
  - name: GCP Artifact Registry
    prefix: europe-west1-docker.pkg.dev
    api_url: https://europe-west1-docker.pkg.dev
    credentials: ext:/auth/auth.sh
    credsexpire: 30m
```

## Secrets Management with External Secrets Operator

Sensitive values like Slack API tokens are stored in Google Cloud Secret Manager and pulled into the cluster using External Secrets Operator. A `ClusterSecretStore` connects to GCP Secret Manager, and individual `ExternalSecret` resources reference specific secrets:

```yaml
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: argocd-notifications-secret
  namespace: argocd
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: gcp-secret-manager
    kind: ClusterSecretStore
  target:
    name: argocd-notifications-secret
    creationPolicy: Owner
  data:
    - secretKey: slack-token
      remoteRef:
        key: slack-token
        version: latest
```

This keeps secrets out of Git entirely while remaining declaratively managed.

## Pub/Sub-Based Autoscaling

The application processes messages from Google Cloud Pub/Sub, so CPU alone isn't enough for scaling decisions. The HPA is configured with both CPU utilization and Pub/Sub unacknowledged message count:

```yaml
metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: External
    external:
      metric:
        name: pubsub.googleapis.com|subscription|num_undelivered_messages
      target:
        type: Value
        value: "50"
```

When the message backlog grows — even if CPU is idle — the cluster scales out to clear the queue. This was critical for handling bursty workloads where message volume spikes don't always correlate with compute pressure.

## Slack Notifications

ArgoCD notifications push sync events to Slack for visibility. The ConfigMap defines templates for success, failure, and health degradation events:

```yaml
service.slack: |
  token: $slack-token
subscribe.on-sync-failed.slack: '#argocd-img-updater'
subscribe.on-sync-succeeded.slack: '#argocd-img-updater'
```

Every deploy posts the app name, sync status, and a link to the ArgoCD dashboard. Simple, but it means the team knows what shipped without checking anything.

## What I Learned

**SemVer tagging works well with Image Updater.** Using `1.0.{run_number}` gives you predictable, sortable tags that Image Updater can compare. Avoid mutable tags like `latest` — they break the update detection.

**The OAuth2 metadata approach is clean.** Instead of managing service account keys as secrets, using the GKE node's metadata endpoint for registry auth keeps the credential management simple and rotation-free.

**Guard against feedback loops.** The `github.actor != 'argocd-image-updater'` check in the CI workflow prevents the Image Updater's Git write-backs from triggering new builds. Miss this and you get an infinite loop.

**Multi-metric HPA needs tuning.** The Pub/Sub threshold was something I iterated on — too low and pods scale up on every small burst, too high and the queue backs up. Start conservative and adjust based on real traffic patterns.

The full implementation is on [GitHub](https://github.com/xokacar/cloud-native-gitops-argocd-helm-image-updater).


How I implemented ArgoCD Image Updater to automate container image deployments on Google Kubernetes Engine, with Helm charts, Pub/Sub-based autoscaling, External Secrets, and Slack notifications.

Automating Kubernetes Deployments with ArgoCD Image Updater on GKE


Managing identical infrastructure across dev, staging, and production without copy-pasting Terraform files is the kind of problem that Terragrunt was built to solve. I set up a complete IaC pipeline on GCP that provisions GKE clusters, VPC networking, and Cloud CDN across three environments — all from a single set of modules.

## The Architecture

The pipeline provisions three core components per environment:

- **GKE cluster** for running workloads
- **VPC** for network isolation with proper subnetting
- **Cloud CDN** backed by GCS buckets for static content delivery

Each environment (dev, staging, prod) gets its own instance of these resources with environment-specific configurations.

## Project Structure

The repo separates Terraform modules from Terragrunt environment configurations:

```
iac-infra/
├── terraform/
│   ├── main.tf
│   ├── variables.tf
│   ├── envs/
│   │   ├── dev/
│   │   │   └── terragrunt.hcl
│   │   ├── staging/
│   │   │   └── terragrunt.hcl
│   │   └── prod/
│   │       └── terragrunt.hcl
│   └── modules/
│       ├── gke/
│       ├── vpc/
│       ├── cdn/
│       └── cdn_bucket/
├── .github/
│   └── workflows/
│       └── ci-pipeline.yml
```

The `modules/` directory contains reusable Terraform code. Each module handles one infrastructure concern. The `envs/` directory contains Terragrunt configs that call those modules with environment-specific inputs.

This is the DRY pattern Terragrunt enables: write the module once, call it three times with different variables.

## The CI/CD Pipeline

The GitHub Actions pipeline automates the entire lifecycle. It triggers on:

- **Pull requests** to `main` — runs `terragrunt plan` so reviewers can see what changes before merging
- **Pushes to `main`** or environment tags (`*-dev`, `*-staging`, `*-prod`) — runs `terragrunt apply` to provision

The pipeline handles environment detection automatically:

1. Checks out code
2. Authenticates to GCP using a service account key from GitHub Secrets
3. Installs Terraform v1.9.5 and Terragrunt v0.67.5
4. Detects which environment to target based on the branch or tag
5. Imports existing resources if needed (CDN, VPC)
6. Validates the configuration with `terragrunt validate`
7. Runs plan (for PRs) or apply (for pushes to main)

The environment detection means a single pipeline handles all three environments. Push a `v1.2.0-staging` tag and it applies to staging. Merge to `main` and it applies to production.

## State Management

Terraform state is stored remotely in GCS, with the bucket name managed via GitHub Secrets (`TERRAFORM_BUCKET_NAME`). Each environment gets isolated state — a bad apply in dev can't corrupt production's GKE state.

Terragrunt handles the backend configuration centrally, so individual environment configs don't need to repeat the bucket setup.

## Module Design

Each module is focused on one concern:

**VPC Module** — Creates the network, subnets, and firewall rules. The `subnet_cidr` is configurable per environment so CIDR ranges don't overlap (important if you ever need VPC peering between environments).

**GKE Module** — Provisions the Kubernetes cluster with configurable node counts, machine types, and autoscaling. Dev runs minimal nodes; production runs enough for redundancy.

**CDN Module** — Sets up Cloud CDN backed by a GCS bucket. The CDN bucket module handles the storage provisioning, and the CDN module wires up the load balancer and caching rules.

**CDN Bucket Module** — Provisions the GCS bucket that backs the CDN, with appropriate access controls and lifecycle policies.

## What Makes This Work

**Terragrunt's `include` block** lets each environment inherit common configuration (provider setup, backend config) from a parent while overriding just the variables that differ. This eliminated the copy-paste problem completely.

**The plan-on-PR workflow** catches mistakes before they reach any environment. Reviewers see exactly what resources will be created, modified, or destroyed.

**Tag-based deployments** give precise control. Instead of deploying everything on every merge, teams can promote changes through environments by tagging specific commits.

## What I'd Improve

**Add policy-as-code.** Running OPA or Checkov in the pipeline would catch misconfigurations (overly permissive IAM, missing labels) before they get applied.

**Crossplane integration.** Managing infrastructure from within Kubernetes using Crossplane would let application teams self-service without touching Terraform directly.

**Atlantis for PR automation.** Instead of GitHub Actions running plans, Atlantis would post plan output directly as PR comments with apply/reject controls.

The full implementation is on [GitHub](https://github.com/xokacar/iac-infra).


Building a scalable IaC pipeline for dev, staging, and production on Google Cloud Platform using Terraform modules, Terragrunt environments, and automated CI/CD with GitHub Actions.

Blog

Claude Code Was Hallucinating. The Fix Was a Progress Bar.

My Kubernetes Cluster Looked Healthy. Production Wasn't.

Automating Kubernetes Deployments with ArgoCD Image Updater on GKE

Multi-Environment Infrastructure on GCP with Terraform and Terragrunt