Application Triage Field Kit — offline app-layer incident triage

Application Triage / Field Kit

The app is misbehaving — start here. A calm decision flow for the application layer: errors, slowness, connection failures, and bad deploys. It points you at the signal to check and the most likely cause. It reads your dashboards; it doesn't touch your systems.

🌿 Breathe. Most app incidents have a boring cause — a deploy, a full pool, a slow dependency. Work one branch at a time. You'll find it.

What is the app doing? Open the branch that matches. The #1 cause is almost always a recent change — check deploys first.

Errors are up (5xx / exceptions)

Check

Did a deploy or config/flag change go out just before the spike? (align the timelines)
Error rate by service and endpoint — is it one thing or everything?
Top exception / stack — one dominant error?
Are the errors coming from a dependency (DB, cache, queue, 3rd-party)?

First move: if it lines up with a deploy, roll back or flip the flag before diagnosing. Otherwise isolate the one failing dependency or endpoint.

It's slow (latency up)

Check

p95 / p99 latency by endpoint — where is the time actually spent (app vs DB vs downstream)?
CPU, memory, and GC pauses on the app tier
Slow queries / DB latency (hand off to the DB Field Kit)
Thread pool or connection pool saturation

First move: follow the time — an APM trace usually shows whether it's your code, the database, or a dependency. If a tier is saturated, shed load or scale it.

Can't connect / timeouts

Check

Is the service actually up and passing health checks?
Connection pool exhausted? (waits for a connection look like timeouts)
DNS / load balancer / DB max_connections
Is a circuit breaker open, or are retries stampeding?

First move: confirm the service and its dependencies are reachable. Pool exhausted → restart/scale and find what's holding connections. Don't let retries pile on.

Right after a deploy

Check

Exactly what changed — code, config, feature flag, or a schema migration?
Canary vs full rollout — is it only the new version erroring?
Any flag that can be flipped without a full redeploy?

First move: roll back or flip the flag. Deploys are the single most common cause — restore service first, root-cause the change after.

A dependency is down

Check

Which one — database, cache, queue, or a third-party API?
Its status page / health, and your timeout + retry settings against it
Is there a fallback, cache, or circuit breaker you can lean on?

First move: fail over or use the fallback, and stop the retry storm (open the breaker, add backoff). Protect the rest of the app from the one bad dependency.

Plain signals — is what you're seeing normal, degraded, or an emergency?

Signal	Healthy	Trouble
Error rate	at baseline	spiking → find what changed
p95 latency	steady	climbing → a tier is saturated or a dependency is slow
Connection pool	has headroom	exhausted → "timeouts" that aren't really the network
Deploy correlation	none	spike starts at deploy time → roll back first
Dependency health	green, fast	timing out → fail over / fallback, stop retries
Traffic	expected shape	spike or retry storm → shed load, rate-limit

Don't assume the runtime, the version, or the environment. Confirm what's actually deployed where — language/runtime version, container vs VM, and that prod isn't running the canary (or vice-versa). The fix that works in one often doesn't in the other.

Application Triage Field Kit — a ReliabilityOps tool. Offline, single-file; it reads your observability, it doesn't touch your systems. Adapt to your stack and runbook. Nothing on this page calls the network; your timeline never leaves the browser.