In 30 seconds
- Setting: payday morning at a regional bank. Internet banking is up, but customers can't finish their transfers.
- What Motadata did: Motadata ObserveOps traced the slowdown to one microservice and showed it was flooding an outside provider; Motadata ServiceOps held the change record that explained why.
- Business point: Astiostech, a Malaysian technology company, implements Motadata ObserveOps, a unified observability platform, and Motadata ServiceOps, an ITSM, ITAM and patching platform. Together they help banks find the real cause of an internet banking slowdown before the blame game starts.
The problem: internet banking that is "up" but unusable
Most internet banking platforms are no longer one big application. They are built from many smaller services, often called microservices, such as login, accounts, transfers and notifications, plus outside providers for SMS codes and payments. Each service can be released by its own team on its own schedule.
That design makes change faster. It also makes problems harder to see:
- Customers feel one slow step as the whole bank being down, while most IT dashboards still show green.
- One slow service sets off alerts everywhere, so teams read hundreds of alerts and tickets instead of fixing one cause.
- The first suspect is usually outside the building, often the telco or a payment provider, and hours go into escalation calls.
- Recent releases are rarely connected to the problem quickly, because change records and monitoring live in different places.
- Weak warning signs at quiet hours get missed, then become a crisis at peak time.
Payday is when all five arrive together.
The story
At 8:47am on the twenty-fifth, Devi's teh tarik was still too hot to drink, and internet banking at Teratai Bank was already too slow to use.
Not down. Devi would have preferred down. Down is honest. This was the other thing: customers could log in, watch their salaries arrive, tap "Transfer", and then wait for a one-time code that moved like a lorry reversing down a narrow lane with three men waving it in.
Two years ago, internet banking had been one large application. Now it was a dozen smaller services, each released by its own team on its own schedule. Releases were faster. Mornings like this were harder to read.
Her Motadata ObserveOps dashboard laid the services out as they really were. Real user monitoring showed customers stuck on the transfer confirmation page. Login was green. Accounts were green. Transfers were amber. The notification service, the one that sends each code by SMS, was red. Traces of the slow transfers all ended in the same place: the notification service, waiting on its outside link to the telco.
ObserveOps had already opened a priority one incident in Motadata ServiceOps, with the slow traces attached. Behind it, tickets were piling up from branch staff, contact centre agents and colleagues trying to pay their own bills, and incident clustering folded them all into the same incident. One incident, not two hundred tickets. Devi was grateful. The contact centre manager standing beside her desk was less so.
Puan Norliza had brought her own evidence: a tally of calls on a sticky note, which had run out of space and continued onto the back of her hand. "Customers think we've been hacked," she said. "One uncle says he is moving his savings under his mattress." Devi promised her an answer within the hour and a holding message for the website within ten minutes, and sent the second one before she had the first.
"It's the telco," said Hafiz, already dialling. "It's always the telco."
The evidence did point that way. Cross-domain correlation tied the red service to the outside SMS link. Every trace said the same thing: our service is waiting for them.
Devi held up a hand. Something about the notification service bothered her. Not its speed. Its volume.
She opened its application view. Customers had asked for a lot of codes this morning, payday-busy but normal for payday. The notification service was sending several times more requests to the SMS link than customers had asked for. It wasn't only waiting for the telco. It was shouting at it.
"Hafiz. Hang up for a minute."
She scrolled back through the night. Anomaly detection had flagged a jump in the service's outbound requests at 2:14am, and a low-priority ticket had duly appeared in ServiceOps. On a quiet night it looked like a small oddity in a small hour. Nobody had opened it.
She switched to ServiceOps and pulled the change records for the notification service. Thursday, 11:10pm: new release, "improved retry handling". Approved, tested, deployed on schedule.
Improved, it turned out, meant enthusiastic. When the SMS link replied slowly, the new version simply asked again, and again. On a quiet night that was harmless. On payday morning every reply was slow, so every code was requested several times over, which made the link slower, which made the service ask more. The bank was queuing behind itself.
Hafiz's phone buzzed. It was a message from the telco's account manager, who had clearly been watching his own screens: "Before you ask. One sender has been flooding our gateway since Thursday night. It's you."
"So," said Hafiz carefully. "Not the telco."
"Not this time."
Now came the decision no dashboard could make. Arif, the developer who owned the notification service, joined by video from the car park. "Give me two hours," he said. "I'll patch the retry limit and push a fix."
Two hours of late codes, on payday, with a fix written under pressure. Or a rollback: a few minutes with no codes sent at all, then the old, boring, well-behaved version. Devi chose boring. She raised an emergency change in ServiceOps, attached the ObserveOps traces, the anomaly ticket and Thursday's change record, and sent it to Encik Azman, the CIO, for approval.
Encik Azman was in a dental chair. He approved it with one thumb. The dentist was not consulted.
The rollback started at 9:31am. Devi watched the notification service's outbound requests drop back until they matched what customers were actually asking for. The traces shortened. On the real user monitoring view, the transfer confirmation page went from amber to green, one region at a time. Hafiz's phone buzzed again: "Queue draining. Thank you." Puan Norliza replaced the website message with an all-clear and washed her hand.
Devi wrote the post-incident note in ServiceOps herself, before anyone could write it for her. Cause: our release. Detection: traces and request volume, confirmed by the telco. Fix: rollback. Follow-up: retry handling to be redesigned and tested against a slow SMS link, not just a fast one. Anomaly tickets on customer-facing services to go to the on-call engineer, not a queue nobody reads at 2am.
Arif replied within a minute: "Agreed. Sorry. Also my dentist is now asking about you."
She finally picked up the teh tarik. It was cold. Across the room, Hafiz had opened the 2:14am ticket and was reading it the way people read a letter that arrived three days late.
On the whiteboard behind him, someone had written: "Days since we blamed the telco: 0." Under it, in Hafiz's handwriting: "Correctly: also 0."
Key points: the problem and how Motadata solved it
FAQ
What is Motadata ObserveOps? Astiostech, a Malaysian technology company, implements Motadata ObserveOps, a unified observability platform. It covers hybrid infrastructure, application and network monitoring, traces, log monitoring, real user monitoring, SLO monitoring and network configuration compliance, with AI anomaly detection and cross-domain correlation.
Can Motadata ObserveOps monitor microservices in internet banking? Yes. Motadata ObserveOps combines application monitoring and traces with real user monitoring, so a bank can see how each service performs, where a slow request spends its time, and what customers experience. Coverage for a specific architecture should be confirmed during a health check.
How do Motadata ObserveOps and Motadata ServiceOps work together? Alerts in Motadata ObserveOps can automatically create incidents in Motadata ServiceOps, with monitoring context attached. ServiceOps then manages the tickets, changes and approvals that follow.
What does Motadata ServiceOps add for banks? Astiostech implements Motadata ServiceOps, an ITSM, ITAM and patching platform. It provides a service desk with change management, IT asset management and CMDB, patch and endpoint management, workflow orchestration, and AI ticket categorisation, routing and incident clustering.
What does Astiostech do for Motadata customers in Malaysia? Astiostech implements Motadata products: discovery, architecture, deployment, integration, training and ongoing support. Read more on the Motadata page.
Schedule a call with us
Book a 20-minute monitoring health check
Disclaimer
This story is fiction. Teratai Bank and every person in it are imaginary. The product capabilities shown are taken from Astiostech's published product information and capabilities confirmed by Astiostech.