LEARN. PRACTICE. GROW.Define a comparable observation
Before testing, record origin, destination, requested name, port, protocol, and execution context. A laptop request may cross a proxy that the APS service does not use. It may also use another identity, trust chain, or client configuration. Success on that path does not establish success on the affected path. In a workshop, draw both paths and mark each known difference. Choose the next observation to reduce one of those differences within authorized access. Do not copy entire environment variables into a ticket: describe relevant configuration without disclosing secrets. Keep the result and its limitations beside the hypothesis being investigated.
Read curl cumulative milestones
Timings reported by write-out require attention to their starting point. On a new direct HTTPS request without redirects or reuse, time_connect ends at TCP connection and time_appconnect at the TLS handshake. With 0.12 and 0.42 seconds, the difference is 0.30. Do not add these values as independent phases. If the first byte arrives at 2.42 seconds, two seconds elapsed after the handshake. That interval may include sending, transit, queues, and dependency work; it does not establish two seconds of CPU. For proxy, redirect, or reused-connection flows, revisit interpretation and collect additional context. The exercise is a bounded milestone reading, not a complete application profile.
Change an address without losing identity
In an authorized direct lab, --resolve can associate reports.example:443 with a specific address while retaining https://reports.example/ in the URL. This lets you compare a destination while keeping the requested name. Replacing the URL with an IP changes the identity used in negotiation and can select another virtual host. Using --insecure removes a verification important to diagnosis; disappearance of an error in that mode does not mean identity is correct. Also record the proxy and exclusion rules actually applied. An option changing the path does not authorize bypassing production controls. The workshop aims to understand which variable changes and which remain constant, using reserved example names and addresses.
Waiting limits and uncertain outcomes
A connection limit is not the same as a whole-operation limit. In curl, --connect-timeout covers resolution and requested handshakes; after connection, the request may continue waiting. Also define a suitable overall limit when that is the test’s purpose. For operations with side effects, a client-observed timeout does not demonstrate remote rejection. In a funds-instruction exercise, look up state using the original identity and confirm the retry contract before resending. A new identity may be treated as another operation. Coordinate mitigation with the responsible person and preserve the attempt sequence. Do not use unlimited retries as a substitute for reconciliation or diagnosis.
Interpret PostgreSQL state and blocking
In PostgreSQL 18, idle in transaction indicates an open transaction with no query executing at that moment. It does not mean the session ended or prove it is blocking others. If pg_blocking_pids(510) returns 412, that observation relates 412 to 510 waiting for a lock. The relationship can involve a conflicting holder or an earlier waiter in the queue. Record time, sessions, and authorized context without publishing sensitive SQL text. Bring the need to confirm impact and choose mitigation to the DBA. The function also has cost; very frequent calls can affect performance. Bounded collection authorizes neither session termination nor a claim that the same relationship persisted throughout the incident.
Workshop for reproducible technical escalation
Use the synthetic record shown and write three sentences: observation, hypothesis, and next check. For example, the interval between TLS and first byte is high compared with the healthy case, but it is not yet known whether time is spent in the application or a dependency. Attach origin, path, and a correlatable request. If a blocking snapshot exists, identify its time rather than presenting it as complete history. A colleague should be able to repeat the reasoning without credentials or real customer data. Ask them to find another explanation compatible with the same signals. End the workshop with a specific request to the relevant team and a criterion for accepting or rejecting the hypothesis.
# Synthetic observation from one fresh direct HTTPS request
# No proxy, redirects, connection reuse or production execution.
time_namelookup=0.02
time_connect=0.12
time_appconnect=0.42
time_starttransfer=2.42
time_total=2.52
# TCP-to-TLS interval: 0.42 - 0.12 = 0.30 seconds
# TLS-to-first-byte interval: 2.42 - 0.42 = 2.00 seconds
# These intervals do not isolate application CPU or database time.On a new connection, time_connect=0.12 and time_appconnect=0.42 indicate a 0.30 s interval between completed TCP and TLS. They do not isolate application CPU.
Common pitfalls
Adding cumulative times; comparing laptop and service without context; disabling TLS verification; treating idle in transaction as completed; terminating blockers without authorization.
Related topics: Useful hypotheses and evidence · Operational mitigation and validation · Handover and improvement
Useful diagnosis narrows possible explanations and records limits. A successful command does not replace validation of the business outcome.
Reference: curl command line manual · Operational support; PostgreSQL 18, OpenSSL 3.5 and BIND 9.20.29 examples; reviewed 2026-09-30