Cloudflare SE Lab
Lab 10

Observability and troubleshooting runbook

Lab 10 brings the full Cloudflare SE lab together into a repeatable troubleshooting workflow for DNS, redirects, cache, WAF, rate limiting, Tunnel, Access, headers, and edge behavior.

Scenario

A customer says Cloudflare is slow, blocking traffic, caching incorrectly, or behaving differently than expected. The goal is to triage calmly and determine whether the issue is DNS, TLS, routing, cache, WAF, rate limiting, Access, Tunnel, origin behavior, or application logic.

Objective

Build and use a repeatable Cloudflare troubleshooting runbook. The runbook separates symptoms from control-plane behavior, validates each layer with command-line checks, and provides a clean Solutions Engineer operating model for customer calls.

Outcomes

  • Created a repeatable triage workflow for Cloudflare-hosted application behavior.
  • Validated DNS resolution and hostname routing with dig.
  • Validated HTTP status codes, response headers, redirects, and Cloudflare edge headers with curl.
  • Used cf-cache-status to reason about cache behavior.
  • Validated WAF behavior against intentionally protected paths and query patterns.
  • Validated rate limiting behavior against the login API path.
  • Validated R2-backed private asset access through Worker-controlled headers.
  • Validated Zero Trust Access and Tunnel behavior for the protected internal hostname.
  • Connected all previous labs into one operational troubleshooting model.

Environment / Build

  • Primary site: https://www.ybarra-cflab.com/
  • Canonical app route: https://www.ybarra-cflab.com/app/
  • App redirect source: https://app.ybarra-cflab.com
  • Diagnostics: /health/, /diagnostic/, and /headers/
  • Cache paths: /static/logo.txt, /cache/demo, and /api/time
  • WAF paths: /admin, /upload, and /upload?attack=true
  • Rate limiting path: /api/login
  • R2 protected asset: /assets/test.txt
  • Zero Trust hostname: internal.ybarra-cflab.com
  • Runbook location: ~/Documents/cf-lab-site/runbooks/cloudflare-triage.md
  • Tools: dig, curl, cloudflared, browser validation, and Cloudflare dashboard events

Demonstrable Content

DNS and hostname validation:

dig ybarra-cflab.com
dig www.ybarra-cflab.com
dig app.ybarra-cflab.com
dig +trace www.ybarra-cflab.com

HTTP headers and request routing:

curl -I https://www.ybarra-cflab.com/
curl -I https://www.ybarra-cflab.com/health/
curl -I https://www.ybarra-cflab.com/diagnostic/
curl -I https://www.ybarra-cflab.com/headers/

Redirect chain validation:

curl -IL https://app.ybarra-cflab.com

Cache validation:

curl -I https://www.ybarra-cflab.com/cache/demo
curl -I https://www.ybarra-cflab.com/cache/demo
curl -I https://www.ybarra-cflab.com/api/time

WAF and rate limiting validation:

curl -I https://www.ybarra-cflab.com/admin
curl -I https://www.ybarra-cflab.com/upload
curl -I "https://www.ybarra-cflab.com/upload?attack=true"
for i in {1..10}; do curl -I https://www.ybarra-cflab.com/api/login; done

R2 and Zero Trust validation:

curl -i https://www.ybarra-cflab.com/assets/test.txt
curl -i -H "x-lab-token: demo123" https://www.ybarra-cflab.com/assets/test.txt
curl -I https://internal.ybarra-cflab.com

What Was Completed

  • Created a Cloudflare triage runbook that covers DNS, HTTP, redirect, cache, WAF, rate limiting, R2, and Zero Trust troubleshooting.
  • Built a command set that can be reused during a customer-facing troubleshooting conversation.
  • Validated that DNS, proxying, routing, and response behavior can be tested independently.
  • Validated that Cloudflare edge headers and response codes help identify which layer handled the request.
  • Validated cache behavior using repeated requests and response headers.
  • Validated security behavior using blocked and allowed request patterns.
  • Validated private object access and identity-aware application access as part of the broader request-flow story.
  • Created a calm, repeatable process for separating symptoms from root cause.

Lab 10 Technical Summary

Lab 10 created a practical Cloudflare troubleshooting runbook that ties together the full lab environment. The runbook starts with DNS resolution and delegation, then moves through TLS, HTTP status codes, redirects, routing, headers, cache behavior, WAF enforcement, rate limiting, R2 object access, and Zero Trust Access/Tunnel validation. This lab is less about adding a new control and more about building the operational process a Solutions Engineer needs during a real customer call: isolate the symptom, identify the layer involved, validate the request path, inspect response headers and events, and prove whether Cloudflare or the origin/application generated the behavior.

Lab 10 Customer-Facing Summary

We created a repeatable troubleshooting runbook for the Cloudflare environment. If a customer reports that traffic is slow, blocked, redirected incorrectly, or cached unexpectedly, this process gives us a structured way to investigate. We check DNS first, then confirm whether traffic is reaching Cloudflare, inspect redirects and headers, validate cache status, review security behavior, and confirm whether private application access is working as expected. The result is a clear, calm process that separates the symptom from the actual control or layer causing it.