Executive Summary: September Insights
- Improved Stability: September showed a positive trend with a 19% reduction in total errors (2,018) compared to August (2,488), indicating improved overall system stability.
- Application Focus Areas: The My Bank and QIB applications remain the primary sources of errors, although QIB errors decreased significantly. My Bank Fund Transfers were the single most impacted journey with 314 incidents.
- Error DistQIBution: Errors were almost evenly split between Business (50.8%) and Non-Business (49.2%) categories, with 1,026 and 992 incidents respectively.
- Key Success: Daily error rates remained consistently lower and more predictable throughout September compared to the volatile spikes seen in the previous month.
Critical Incidents Raised
2,018
Total
Overall Error Spike
-19%
vs August
Error ContQIBution (Sep)
Top 5 Impacted Applications
- 1. QKMyBank Fund Transfer...314
- 2. IB IMPS Fund Transfer110
- 3. IB Add Delete Biller107
- 4. CMS File Upload Auth...84
- 5. CMS Batch TPT Payee...76
Competitor Performance Benchmark - September 2025
| Journey | Performance (s) ↓ |
Availability (%) ↑ |
No. of Steps ↓ |
|||
|---|---|---|---|---|---|---|
| QK | Rank | QK | Rank | QK | Rank | |
| QIB Login (Web) | 4.28s | 3 | 100% | 1 | 3 | 2 |
| Login (Android) | 4.29s | 1 | 100% | 1 | 2 | 2 |
| IMPS (Web) | 7.56s | 2 | 99% | 3 | 4 | 2 |
| IMPS (Android) | 22.11s | 3 | 100% | 1 | 6 | 3 |
Note: Competitors include HDFC Bank, IDFC Bank, Axis Bank.
Error Volume Growth (August vs September)
Business vs Non-Business - Monthly Comparison
Top 5 Impacted Journeys by Error Count (September)
September Daily Error Timeline
Deep Dive: Top Journeys by Error Count (September)
My Bank (646 Errors)
-
Fund Transfer NEFT (Android)314 Errors
Page: Third Party Fund Transfer OTP Entry and Neft Successful Page
Error: "The page did not load" -
Bill Payment Recharge (Iphone)33 Errors
Page: QK Mobile Recharge Confirmation Page
Error: "currently biller is not available "
QIB (729 Errors)
-
IMPS Fund Transfer110 Errors
Page: OTP Response
Error: "Otp not received" -
Add/Delete Biller 107 Errors
Page: Confirm Transaction
Error: "We are unable to process your request."HAR Analysis: Add/Delete Biller
Comparison between a successful transaction and two error instances reveals a critical difference in the server's final response.
Successful Call (TTFB): ~0.1sError Call (TTFB): ~0.17sThe server response time (TTFB) is fast in all cases, but the content of the response differs significantly.
Root Cause: Backend Exception
The server returns a header
exceptiontype: BEin the failing transactions. This indicates a backend exception is occurring, preventing the confirmation page from loading and displaying a generic error message instead.Recommendations:
- Review Server Logs: Investigate backend logs for the `FinacleRiaRequest` endpoint at the timestamps of the errors to identify the specific exception being thrown.
- Validate Request Payload: Check if there are any differences in the data sent to the server between successful and failed requests that might trigger this backend error.
CMS (359 Errors)
-
File Upload Authorizer 84 Errors
Page: List of Batch File
Error: "Batch file not available"HAR Analysis: File Upload Authorizer
Analysis of successful vs. failed sessions shows that in the error cases, a key API call to fetch the list of files is never made.
Successful Call: API call madeError Call: API call missingThe successful HAR shows a `loadPaginatedInformation` API call, which retrieves the data for the batch file list. This call is absent in the error HARs.
Root Cause: Client-Side Scripting Error
A JavaScript error is likely preventing the execution of the function that triggers the API call to load the batch files, resulting in an empty list and the "Batch file not available" message.
Recommendations:
- Review Client-Side Logs: Check the browser console for JavaScript errors on the "List of Batch File" page.
- Debug Page Load Sequence: Step through the JavaScript execution on page load to ensure the function responsible for calling `loadPaginatedInformation` is being triggered correctly.
-
Batch TPT Payee Releaser 76 Errors
Page: Action Remark
Error: "The page did not load"HAR Analysis: Batch TPT Payee Releaser
Analysis shows the client makes a request to perform an action, but the server responds with an HTML error page instead of the expected data.
Expected Response: JSONActual Response: text/htmlThe `rejectMulti` API call receives a `200 OK` status, but the content is an error page, which the client-side script cannot process.
Root Cause: Unhandled Backend Error
The backend is encountering an unhandled exception while processing the "release" action. This causes it to return a generic HTML error page to the AJAX call, leading to a client-side failure.
Recommendations:
- Check Server Logs: Investigate logs for the `/app/gridN/rejectMulti` endpoint for exceptions corresponding to the failure timestamps.
- Implement Proper API Error Handling: Ensure the backend returns structured JSON error messages (e.g., with a 4xx or 5xx status code) for API calls, instead of HTML pages.
CIB (148 Errors)
-
Corp TPT Checker 38 Errors
Page: Transaction Approved
Error: "The page did not load"HAR Analysis: Corp TPT Checker
Analysis of successful vs. failed transactions shows a critical server-side delay when approving the transaction.
Successful Call (TTFB): ~3.3sError Call (TTFB): ~60sThe primary API call, `FinacleRiaRequest`, takes over 60 seconds to get a response in the error cases, while a successful transaction responds in just over 3 seconds.
Root Cause: Severe Server-Side Processing Delay
The extreme Time To First Byte (TTFB) indicates a major bottleneck in the backend application or database layer. The server is taking too long to process the approval request before sending a response.
Recommendations:
- Prioritize Backend Log Review: Immediately investigate server logs for the `FinacleRiaRequest` endpoint related to the CIB transaction approval flow at the failure timestamps.
- Analyze Database Performance: Examine the database queries executed during this process. A slow or complex query is the likely cause of the extended processing time.
- Check External Dependencies: Verify if any third-party API calls made during this process are timing out or responding slowly.
-
Fastag Bill Payment 18 Errors
Page: Customer Details
Error: "We are unable to process your request."HAR Analysis: Fastag Bill Payment
Comparison between successful and failed transactions reveals a significant server-side processing delay and a backend exception.
Successful Call (TTFB): ~4.2sError Call (TTFB): ~23sThe `FinacleRiaRequest` API call takes significantly longer in error cases. Crucially, the failing response includes a header
exceptiontype: BE.Root Cause: Backend Exception & Processing Delay
The combination of a long server response time and the `BE` exception header indicates a server-side process is both timing out and crashing. This prevents the customer details from being fetched, leading to the generic error message.
Recommendations:
- Investigate Backend Logs: Prioritize analysis of server logs for the `FinacleRiaRequest` endpoint during the Fastag journey to identify the specific exception and the cause of the long delay.
- Review External Dependencies: Check if this process relies on an external service (e.g., NPCI for Fastag details) that might be slow or unresponsive.
- Optimize Database Queries: Analyze the database queries involved in fetching customer and biller details for performance bottlenecks.
My Card (83 Errors)
-
Registration (Android)14 Errors
Page: Registration Details
Error: "Verification not Successful." -
Landing Page (iPhone)6 Errors
Page: Mycard Landing Page
Error: "Service unavailable"
DigiRemit (47 Errors)
-
DigiRemit Login 11 Errors
Page: International Money Transfer Page
Error: "Service unavailable"HAR Analysis: DigiRemit Login
Comparing successful and failed login flows shows that a specific API call fails to load a dashboard component after the main page has loaded.
Successful Calls: 200 OKError Call Response: 200 OK + 'BE' HeaderIn the error cases, the API call to load the `DashboardMailViewInboxUX5` widget responds with a `200 OK` status but includes a custom header:
exceptiontype: BE.Root Cause: Unhandled Backend Exception
The `BE` (Backend Exception) header indicates the server failed while trying to fetch the data for the user's message inbox widget. The application does not handle this gracefully, resulting in a generic "Service unavailable" error.
Recommendations:
- Examine Server Logs: Investigate the `FinacleRiaRequest` logs for exceptions related to loading the `DashboardMailViewInboxUX5` widget during the DigiRemit login flow.
- Improve API Error Handling: The API should return a proper HTTP error code (e.g., 500) and a structured JSON error message instead of a 200 OK with a custom header, allowing the frontend to fail more gracefully.
Deep Dive: Slowest Screens by Response Time (September)
Top 6 slowest pages based on average response time, with HAR analysis for identified bottlenecks.
HAR Analysis Findings
Comparison between two transactions (93.45s vs 78.13s) reveals a critical bottleneck in client-side processing.
The core API call to `FinacleRiaRequest` is extremely fast. However, the total time indicates that the vast majority of the delay occurs after the server has already responded.
Root Cause & Recommendations
Root Cause: Intensive Client-Side Processing
The primary bottleneck is heavy JavaScript execution after the server responds. This blocks the browser's main thread, freezing the UI and delaying the page from becoming interactive for over 90 seconds.
Recommendations to resolve:
- Profile Client-Side Scripts: Use browser developer tools (Performance tab) to identify and optimize long-running JavaScript functions that are triggered on this page.
- Break Up Long Tasks: Defer non-essential scripts and chunk long-running code into smaller tasks using `setTimeout` to prevent UI freezing.
- Optimize Data Payload: Investigate if the HTML payload returned from the API can be minified or simplified to reduce the client-side parsing and rendering workload.
HAR Analysis Findings
Analysis of two separate transactions reveals a consistent and severe server-side processing delay.
In both cases, the `FinacleRiaRequest` API call is responsible for almost the entire duration of the transaction, indicating the bottleneck is not on the client side.
Root Cause & Recommendations
Root Cause: Critical Server-Side Processing Delay
The extended Time To First Byte (TTFB) of 25-30 seconds points to a major issue within the backend application logic or database layer when fetching or preparing the biller details page.
Recommendations to resolve:
- Immediate Backend Triage: Prioritize investigation of the `FinacleRiaRequest` endpoint for this specific "Add Biller" journey. Analyze server logs corresponding to the transaction timestamps.
- Database Performance Review: Examine the efficiency of database queries executed for this page. The delay may be caused by complex joins, unindexed columns, or table locks.
- External Service Calls: Determine if this process relies on third-party APIs (e.g., for biller validation). If so, check for timeouts or slow responses from those external services.
HAR Analysis Findings
Comparison between two CIB NEFT transactions highlights a significant server-side delay in one instance.
The `FinacleRiaRequest` API call is the source of the delay. In the slow transaction, it took over 27 seconds for the server to respond, compared to just 0.6 seconds in the normal one.
Root Cause & Recommendations
Root Cause: Server-Side Processing Delay
The bottleneck is located on the server. The extended Time To First Byte (TTFB) points to issues within the backend application or database while processing the NEFT confirmation request.
Recommendations to resolve:
- Backend Log Analysis: Correlate the slow transaction timestamp with server logs for the `FinacleRiaRequest` endpoint to identify errors, timeouts, or long-running processes.
- Database Query Optimization: Investigate the database queries executed during this transaction. Look for inefficient queries, missing indexes, or database locks that could cause delays.
- Infrastructure Health Check: Review the health of the application server during the incident time. Check for CPU/memory spikes or other resource contention that could slow down processing.
HAR Analysis Findings
Comparison between two MIS report download transactions shows a clear server-side processing delay.
The delay originates from the backend, as the time to first byte (TTFB) for the download request accounts for nearly the entire transaction time in the slower instance.
Root Cause & Recommendations
Root Cause: Server-Side Report Generation Delay
The bottleneck occurs during the server's generation of the MIS report. This could be due to complex data aggregation, inefficient database queries, or high server load.
Recommendations to resolve:
- Optimize Report Generation Logic: Profile the backend code responsible for creating the XLSX file. Focus on optimizing database queries and data processing logic.
- Implement Asynchronous Generation: For large reports, consider an asynchronous process. Notify the user that the report is being generated and provide a link to download it once ready, preventing a long wait.
- Caching Strategy: If the same reports are frequently requested, implement a caching mechanism to serve pre-generated files instead of creating them on every request.