Identify the caller behind a compatibility incident
A server can be healthy while one supported client is broken. Trace the failing contract and client behaviour before treating the incident as a general outage.
Read articleCobnex blogs / Global
Cobnex blog
AI implementation, software architecture and cloud operations for teams worldwide.
456 articles
Page 12 of 26
Continue a saga with one irreversible effect
When a completed step cannot be undone, stop describing recovery as rollback. Establish the remaining business options and preserve the effects already known to exist.
Read articleTrace the job that ran under the wrong account
Contain further work, preserve the job's trusted context and identify every affected artifact. A wrong-tenant job can create consequences beyond its final response.
Read articleDiagnose an event that parsed but meant the wrong thing
When records look plausible but are wrong, trace how the consumer interpreted the message. Successful deserialisation can hide a semantic change.
Read articleFind which cache is still serving the old value
Trace one response through browser, edge and application layers before clearing everything. A broad purge can hide the cause and overload the source.
Read articleA migration is waiting. Find the blocker before retrying
Repeatedly launching the same command can create more contention. Inspect the active database work and choose a controlled recovery action.
Read articleTrace a deadlock to the order of resource access
Retrying can recover one request, but repeated deadlocks need a clearer picture of which transactions acquire which resources.
Read articleDiagnose a platform policy failure at its effective scope
A workload can inherit several layers of control. Identify which rule applies to the actual identity and resource before changing permissions.
Read articleThe restore completed but the application will not start
Diagnose compatibility and dependencies before repeating the restore. A successful data job can leave the application missing configuration, keys or a usable identity.
Read articleConfirm write authority before changing regional traffic
During an outage, reachable does not necessarily mean safe to use. Establish which data path is authoritative before directing customers to it.
Read articleDo not let the next apply undo incident containment
Before resuming deployments, compare emergency cloud changes with the checked-in definition. Preserve the intended protection through a reviewed reconciliation.
Read articleStop exposure before investigating the release in depth
When a candidate is harming users, use the tested control to limit further impact. Preserve enough evidence to understand what already happened.
Read articleA service objective is burning. Find the affected journey
Start with the operations behind the signal, then use infrastructure evidence to locate the cause. The objective tells you about impact, not automatically the failing component.
Read articleNew connections fail after a rotation
Existing sessions can hide a stale credential until the pool reconnects. Compare target validity, secret version and consumer refresh before rotating again.
Read articleAn invoice export timed out. Establish its outcome first
Before retrying creation, inspect the operation record and the correct Xero organisation. A timeout leaves uncertainty that another request can make worse.
Read articleA CRM value keeps changing back
Repeated reversals usually point to competing writers or a stale full-record update. Trace the field's provenance before making another manual correction.
Read articleThe provider says delivered but the application did nothing
Trace the event from acknowledgement to durable receipt and worker outcome. The missing stage determines whether to replay, repair or reconcile.
Read articleRepeated rate-limit responses need less traffic, not more workers
Identify the shared budget and stop retry amplification before increasing capacity. More concurrency can make a provider throttle harder to recover from.
Read article