Which sites need a closer check?
Compare automated alarms with service counters before you name the affected sites.
The question
You review mobile data service at a South Korean operator. Both records cover the same 15-minute window. The assurance lead owns the incident.
Six alarm rows mean six sites are down. The rows name A, A, B, C, D and D.
| Count | |
|---|---|
| Attempts | 3000 |
| Successful attempts | 2910 |
The success floor is 99%. An attempt may include a retry. The counter covers the named sites together.
“What can you verify from the two records? What do you still need to check?”
Not saved by this site. Your browser may restore text when you navigate back.
A strong answer, step by step
Open each step in turn. This is one strong answer, not the only one.
Step 1: Count distinct sites
What would you do here? Open the move you’d make.
Deduplicate the site IDs and check the service counter.
The strong move. An alarm row identifies a signal. The site ID tells you how many distinct sites the rows name.
Report that six sites are down.
Tempting, but it misses something. A and D each appear twice. The rows name four sites, and the alarm summary has yet to show service impact.
See how a strong candidate says it
“I count four distinct sites across the six rows. I’d check the data session counter before describing any of them as down.”
Why it works: An alarm row identifies a signal. The site ID tells you how many distinct sites the rows name.
Step 2: Measure the service
What would you do here? Open the move you’d make.
Report 97% success and ask for a site breakdown.
The strong move. The service counter gives a measured rate. A site breakdown is still needed to identify which sites fell below the floor.
Tell the lead that 90 people lost service.
Tempting, but it misses something. One person can make more than one attempt. The counter has no unique subscriber count.
See how a strong candidate says it
“2,910 of 3,000 attempts succeeded. That is 97%, two percentage points below our floor. There are 90 failed attempts across the group.”
Why it works: The service counter gives a measured rate. A site breakdown is still needed to identify which sites fell below the floor.
Step 3: Check the site counters
The verified site counters show A at 552 successes from 600 attempts, B at 378 from 400, C at 990 from 1,000 and D at 990 from 1,000. A separate transport alert names a path shared by A and B in the same window.
What would you do here? Open the move you’d make.
Report degradation at A and B and ask the lead to check the shared alert.
The strong move. The site counters locate the lower success rates. The transport alert is a clue to verify.
Declare the shared transport path the confirmed cause.
Tempting, but it misses something. The alert overlaps the two sites and the time window. The lead still has to verify the cause.
See how a strong candidate says it
“A is at 92% and B is at 94.5%. C and D each meet 99%. A and B account for 70 of the 90 failed attempts. I’d ask the lead to check the shared transport alert as a possible cause.”
Why it works: The site counters locate the lower success rates. The transport alert is a clue to verify.
Step 4: Brief the assurance lead
What would you do here? Open the move you’d make.
Give the verified scope and the remaining cause question to the assurance lead.
The strong move. The handoff gives the lead the service, sites, time, size and a question to investigate.
Put all four sites in the customer notice as fully down.
Tempting, but it misses something. C and D meet the stated floor, and the counters show some successful sessions at A and B.
See how a strong candidate says it
“In this 15-minute window, A and B fell below the data session success floor. They accounted for 70 of 90 failed attempts. Please check whether the transport alert explains the degradation. I’ll keep the update tied to these counters.”
Why it works: The handoff gives the lead the service, sites, time, size and a question to investigate.
The answer, in short
- Decision
- Tell the assurance lead A and B fell below the floor and give the source counts.
- Because
- The site counters show 70 failed attempts across A and B. The shared path alert still needs a cause check.
- What would change it
- A fresh counter window or a confirmed cause would change the next update.
Common traps
- Counting repeated alarms as separate sites.
- Using failed attempts as a unique customer count.
Check your answer
- I counted distinct sites.
- I checked the session success rate.
- I used the site breakdown.
- I named the owner and the open cause question.
Last reviewed Nov 11, 2026