Atlassian SRE Craft Interview: Diagnose System Health and Defend Reliability Trade-Offs

The Atlassian SRE Craft interview asks you to turn a system diagram into a reasoned operational discussion: assess health, investigate a failure, and defend reliability decisions. Prepare to explain which observation you need next and how it would change your action. Naming monitoring tools is less useful than connecting evidence to user impact.

Atlassian's official SRE Craft guide describes that three-part progression and an interactive discussion. One recent candidate report describes a similar structure, but one account cannot establish every team's format or questions. Our system diagram, incident numbers, and trade-off exercises are original preparation material.

What is official, reported, and inferred about the format?

Official: Atlassian's public SRE Craft interview guide describes a generic system diagram, discussion of system health, troubleshooting a presented problem, and reliability metrics and practices. The guide lists 60 minutes for Craft and emphasizes communicating throughout the interactive session. Your coordinator's current instructions remain the source for your appointment. Official SRE Craft guide.

Candidate report: a Software Engineer II/P40 candidate says an additional Craft round was scheduled because the role combined backend and reliability work. They report an August 12, 2026 interview lasting about 55 minutes, covering monitoring, incident troubleshooting, and a 99.99% availability discussion. This is the author's account, not an employer-wide requirement. Reported Craft experience.

We found cross-posts of that account, not two independent corroborating candidates. Therefore, this article does not predict an extra seventh round, a universal duration, exact questions, or a passing rubric.

Our inference: the official progression makes evidence-driven rehearsal more useful than memorizing a finished architecture. Practice moving from an observation to a hypothesis, a discriminating check, and a reversible action. The exercises below follow that approach without reproducing an alleged Atlassian interview diagram.

How do you begin assessing an unfamiliar system?

Our diagram contains a client, gateway, API service, database, and background worker. The API serves reads and writes; the worker performs optional asynchronous enrichment. Before listing metrics, establish which user actions depend on each path and what successful completion means.

Ask whether a write response means the data is durably committed, whether reads may be stale, and whether optional enrichment must finish before the customer sees success. These assumptions change both the health signal and the safe degradation strategy. A database chart alone cannot answer them.

Google's SRE book identifies latency, traffic, errors, and saturation as four golden signals. It also distinguishes monitoring symptoms from causes. Those are general SRE concepts, not a statement that Atlassian requires a particular dashboard layout. Primary monitoring guidance.

For this exercise, map signals to the user path. Measure successful and failed request latency separately, traffic at the client and internal attempt levels, externally visible failures, and constrained queues or resources. An average latency can hide a slow tail. A low CPU percentage can coexist with connection-pool exhaustion or a growing database wait queue.

Then explain the next observation you would collect. If write failures rise while reads remain healthy, split the diagnosis by operation. If both degrade after a shared dependency change, inspect that common path. Choose metrics that distinguish your competing hypotheses, so each requested observation has a clear purpose.

What is the first useful statement during an incident?

Start with impact and uncertainty. In our original incident, customers submit about 1,000 requests per second, while the API generates about 2,500 database attempts per second. The database queue grows, tail latency increases, and CPU remains near 40%. A retry configuration changed shortly before the symptoms appeared.

A useful opening is: “Customers are experiencing delayed writes. Internal attempts exceed incoming requests, so I would inspect retries and database waiting before assuming CPU capacity is the bottleneck.” This is a hypothesis supported by the stipulated observations; the timing correlation does not prove causation.

First establish the affected operation, region, tenants, and start time. Check whether requests are failing, succeeding late, or succeeding after client timeouts. That distinction matters for retries: a caller may repeat a write whose first attempt already committed.

Record what changed, but keep alternatives alive. Increased database attempts could reflect retries, larger fan-out, a worker surge, or a different operation mix. Compare attempts per request and trace representative failures. A recent deployment is a lead to investigate, not permission to ignore contradictory evidence.

Which observation would distinguish your hypotheses?

Our hypothesis table uses only facts from this exercise. The tests are recommendations, not commands to run on a real production system during preparation.

Hypothesis	Observation to request	What would weaken it?
Retries amplify load	Attempts per client request and retry reasons	Attempt ratio did not change
A database wait blocks requests	Queue, lock waits, and connection-pool timing	Database response path remains normal
Optional worker activity competes with core writes	Workload mix and dependency usage	Worker load is unchanged and isolated
A configuration rollout introduced the behavior	Version and symptom distribution	Unchanged instances fail equally before rollout

Use a trace to connect one slow customer request with its internal attempts. If retries cluster around timeouts, ask whether timeout budgets allow the original operation to finish and whether retries are bounded. Also check whether the client, gateway, and service each retry: multiple layers can compound work.

Google's overload guidance discusses retry amplification and limiting retries as part of overload control. That supports inspecting the retry policy; it does not establish the cause of our hypothetical incident. Primary overload guidance.

State how you would update the hypothesis. If the configuration explains only one region, investigate the remaining region separately. If the database queue falls after reducing attempts but user failures remain, distinguish recovery lag from a second fault. A strong discussion follows the evidence as it changes.

How do you choose a mitigation before proving the root cause?

For this exercise, the retry configuration is reversible and its earlier version is known. We would evaluate restoring the earlier retry budget while protecting core writes and observing attempts, queue depth, and user success. That recommendation depends on the stipulated reversibility and evidence; it is not a universal instruction to roll back any recent change.

Keep optional enrichment out of the critical path if the product contract permits it. Pausing that worker can reduce competing load, but only if its dependency usage is actually relevant. Explain how the backlog will be handled afterward and what customers will temporarily miss.

Proposed action	Potential benefit	Risk or condition to defend
Restore the earlier retry configuration	Reduce amplified work	Confirm compatibility and retain a rollback path
Bound retries and apply backoff	Limit repeated attempts	Preserve deadlines and write idempotency
Serve approved cached reads	Keep a subset of functionality available	Define acceptable staleness; do not fake write success
Fail over the database	Move away from a failed dependency	Verify replication, capacity, and write ownership

Do not use a read cache as a substitute for a committed write. Do not propose database failover solely because CPU is low or a queue is long. Failover can move the same overload to another instance, expose replication lag, or create conflicting writers if the transition is poorly controlled.

For every mitigation, name its expected signal and stop condition. If attempts fall but successful writes do not recover, say what you inspect next. A mitigation is an operational hypothesis with an observable outcome, not a guaranteed root-cause diagnosis.

How do SLIs and SLOs change the reliability discussion?

Google's SRE workbook describes user-oriented service-level indicators, objectives, and error budgets. Choose an indicator that reflects the service's promised outcome, with a defined numerator, denominator, and measurement window. Primary SLO guidance.

Our request-based example counts eligible write requests that succeed within the agreed deadline. Across an illustrative window, 100,000 requests include 1,200 bad outcomes. Success is 98.8%. A 99.9% objective would permit 100 bad outcomes for that same request count; the observed 1,200 is twelve times that allowance.

The calculation depends on the definition. Excluding timeouts from the denominator would make the indicator misleading. Counting each internal retry as an independent customer request could distort it too. Specify how duplicate attempts map to one eligible user operation and how you handle known invalid requests.

A time-based availability target has different arithmetic. Over a 30-day window of 43,200 minutes, 99.99% availability permits 4.32 minutes of unavailability under that definition. This does not mean every request-based SLO allows exactly 4.32 minutes of downtime. Traffic distribution and the chosen indicator matter.

The candidate's reported 99.99% discussion is a practice cue, not proof that Atlassian imposes that objective on every service or candidate. Defend a target through user needs, dependency limits, and the cost of meeting it rather than treating another nine as an automatic improvement.

How do you defend reliability trade-offs?

Connect each architectural change to a specific failure mode. Multi-zone capacity helps only if traffic can reach healthy capacity and the remaining zones can carry the workload. Replication helps only if its lag and failover behavior fit the data contract. A second component that shares the same failure domain may add cost without the independence you intended.

In our exercise, core writes require one clear ownership path, while cached reads may tolerate explicitly bounded staleness. That difference supports separate degradation behavior. Explain which user functions remain available, which are delayed, and which are rejected safely. “Graceful degradation” needs those concrete outcomes.

Discuss operating cost as well as infrastructure cost. A complex failover design requires testing, alerting, documentation, and an on-call team able to operate it. Our recommendation is to choose the smallest design that addresses the demonstrated risk and meets the stated objective, then verify its behavior under a controlled failure.

After recovery, separate contributing causes from follow-up work. A retry policy change may trigger the incident, while missing attempt-level monitoring delays detection and insufficient dependency isolation broadens impact. Each observation should lead to an owned, verifiable action rather than a vague promise to improve reliability.

How should you communicate during the interactive session?

Make the reasoning easy to follow. Say what you know, what you suspect, what you would check, and what action becomes justified if the check confirms it. Give the interviewer room to supply new evidence; a prepared speech can prevent you from adapting to the actual scenario.

Rehearse one short update: “Write latency is elevated and database attempts are amplified. I am checking retry configuration and wait timing. If the change explains the amplification, I will restore the known earlier policy and watch user success before claiming recovery.” The example makes uncertainty and a decision rule visible.

Bring an incident story that distinguishes your personal contribution from the team's work. Explain an observation that changed your mind, a trade-off you made, and how you verified recovery. The official guide emphasizes communication, but the story structure here is our recommendation, not Atlassian's scoring rubric.

Practice SRE diagnosis and reliability decisions

Question	Craft skill to rehearse
How You Build Service Stability and Troubleshoot Production Incidents	Connect reliability work to measurable user outcomes.
Troubleshoot a production server outage	Ask for evidence that separates competing causes.
Describe an On-Call Incident	Explain mitigation, communication, and recovery checks.
Troubleshoot a Midnight Web Server Outage	Prioritize safe actions under incomplete information.
Troubleshoot a production incident end-to-end	Separate restored service from completed investigation.

Choose another Site Reliability Engineer practice question, sketch the request path, and defend one health measure, one discriminating observation, and one reversible mitigation.

Sources and Further Reading

• Atlassian: Official SRE Craft interview guide
• Candidate report: August 2026 P40 SRE Craft experience
• Google SRE: Monitoring distributed systems
• Google SRE: Handling overload
• Google SRE Workbook: Implementing SLOs

Research checked October 4, 2026. Incident and SLO arithmetic were checked locally. No Atlassian interview, production incident, or reliability experiment was conducted for this article.