Opening: Before the First User Logs In

From bank statement inquiries and account balance checks to bank-corporate direct linkage and regulatory reporting, every business operation of a finance company eventually lands on a specific web page. Whether the page loads properly and returns accurate data directly determines whether group member entities can complete account reconciliation, confirm fund positions, and submit regulatory filings on time.

This is a universal challenge for finance companies, acting as the group’s “in-house bank”: the IT infrastructure may not be large-scale, yet every link is tied to capital flows and regulatory compliance.

Let us share a real-world case. At a finance company, the core system completes end-of-day batch processing every morning before group employees start work. At 5 a.m., the on-call engineer received an alert: three consecutive probe attempts on the “bank statement inquiry” page of the core business system timed out. The operations team intervened and restored the page before users logged in at 9 a.m. No business operations were disrupted that day.

This was no stroke of luck; it was the outcome of a proactive synthetic monitoring system that detects issues ahead of end users.

The finance company serves as the group’s internal bank. Its core business system comprises 9 subsystems and 105 functional modules. It maintains direct connections with 20 commercial banks, interfaces with 17 external systems including group treasury and financial sharing platforms, and connects with 4 regulatory bodies such as the National Internet Exchange of China and the People’s Bank of China. Across the entire platform, there are 146 core scheduled tasks, 171 bank-corporate tasks, and 250 treasury tasks running continuously.

Within such an architecture, a broken web page is never merely an IT issue—it poses risks to fund settlement and regulatory reporting.

Pain Points & Challenges: Comprehensive Monitoring Still Relies on User Trouble Tickets

System stability for finance companies first hinges on business users being able to complete their daily operations.

Challenge 1: Monitoring only covers infrastructure; page failures go undetected

Most finance companies build monitoring starting from the IT infrastructure: hosts, networks, and storage with complete metrics and clean dashboards. However, normal CPU and network status do not guarantee that bank statement inquiries or balance checks work properly. Application-layer page availability is frequently a blind spot in monitoring. Green lights on infrastructure metrics cannot answer business-level questions.

Challenge 2: Fault detection waits for user complaints, which carry financial and regulatory costs

Every web page corresponds to a financial business function: statement inquiries support member entity reconciliation; balance queries underpin fund position management; bank-corporate interfaces handle direct banking connections with dozens of financial institutions. If outages are only uncovered when users call for support, 30 or more minutes may elapse from failure onset to detection. This disrupts daily fund scheduling and, in severe cases, delays data submissions to the People’s Bank of China and the China Foreign Exchange Trade System.

Challenge 3: Traditional probes only test connectivity, not business accuracy

A 200 OK HTTP response on the homepage does not mean the business function works correctly. Even if the backend authentication service fails, the static login page often still returns a 200 status code. For balance query APIs on the bank-corporate platform, successful network connectivity does not guarantee the latest daily balance is returned. Without validating business logic, probes produce false positives and create an illusion that all services are running normally.

These three challenges point to one core requirement: monitoring must shift focus from infrastructure to end-to-end business actions. This marks the starting point for finance companies to evolve from infrastructure monitoring to full business observability.

Solution: Deploy Automated Watchdogs for Key Business Pages

Built on a unified monitoring platform, Lerwei delivers end-to-end proactive synthetic monitoring capabilities to address the above pain points.

1. Multi-protocol probing: Cover three layers on one platform The platform supports WEB (HTTP/HTTPS), Ping, TCP, UDP, Traceroute and other protocols, covering web pages, port connectivity and network links within a single console. What appears as a single page to business users is a full chain of domain name resolution, network routing, port access and application services for monitoring purposes. The tool pinpoints exactly which link breaks whenever a failure occurs.
2. Content-level validation: Embed business logic into monitoring rules Probes check not only HTTP status codes but also match keywords in response content. Judgement criteria are no longer limited to service status codes; they verify whether returned data meets business expectations. For example, the prompt “invalid username or password” serves as proof that the online banking authentication service is functioning properly.
3. Step-by-step simulation: Test complete user workflows Users can orchestrate multi-step scripts to replicate real user journeys: open the page → input parameters → submit requests → validate returned results. Interactive operations such as login and data queries are tested end-to-end instead of only pinging the homepage.
4. Alert linkage to form a closed-loop incident response Synthetic monitoring tasks tie directly to alert policies on the platform. Alerts are triggered after N consecutive failures and pushed to on-call staff, forming a full closed loop: probe → alert → troubleshooting → service recovery confirmation. Early detection is only half the battle; the ability to notify the right personnel and verify service restoration determines whether the monitoring system delivers real value.In this implementation, synthetic monitoring works alongside link tracing, scheduled task monitoring, and deep component monitoring (AS/LB/RDS/HTMQ/K8s, plus Tencent Chitu alert integration) to build a four-tier monitoring system covering Infrastructure → Network Link → Application → Business. Synthetic monitoring sits at the top tier, directly targeting real business activities — the critical missing layer for finance companies upgrading their monitoring architecture.

Practical Implementation Scenarios

Scenario 1: Availability Monitoring for Key Pages on the Core Business System

Among the 105 functional modules of the core system, 19 categories of pages are mission-critical for daily settlement by group members, including user management, workflow configuration, scheduled task administration, bank-corporate interface management, customer data queries, historical account balance inquiries, bank statement searches, deposit information lookups, loan product maintenance, interbank deposit approval, foreign exchange settlement configuration, corporate bank account management, and cash flow project management. These pages run 24/7, and any outage immediately generates business trouble tickets.

The biggest workload lies in selecting monitoring targets rather than configuring probes. The team compiled a Synthetic Monitoring Checklist for Core Systems & Bank-Corporate Platforms, and created individual probe tasks for the 19 key pages. Each task runs periodic HTTP checks with validation on status codes and page content, triggering alerts after repeated failures. Every probe entry clearly documents monitoring targets, validation rules, alert thresholds and responsible teams to build an auditable monitoring ledger.

The ledger enables continuous post-incident reviews: it records why each probe was created, whether thresholds are properly set, and who handled past alerts. Monitoring evolves from a one-time configuration job into a continuously maintained process.

Scenario 2: Business-Level Probing for Balance Queries on the Bank-Corporate Platform

The bank-corporate platform manages direct banking connections with dozens of commercial banks. Account balance queries are the most frequently used function, where data accuracy is paramount. Testing API connectivity is straightforward, but verifying that the system returns the latest daily balance requires simulating an actual business query.

The project implemented business-level synthetic monitoring for balance inquiries: the probe replicates the full user operation flow and uses “display of the latest daily balance on the page” as the success criterion. The test validates not only port connectivity and HTTP status but also the complete business transaction and its output.

This approach translates business requirements into technical monitoring rules. A failed balance query may register only as a timeout or empty return in technical logs, yet it directly leads to incorrect fund position judgements for business teams. Validating against real-time balance data embeds the business team’s top concern directly into monitoring rules — a replicable design for all finance companies running bank-corporate direct linkage systems.

Scenario 3: Online Banking Login Chain Probing: Treating Error Prompts as Health Indicators

User login is the entry point for all corporate banking services. The biggest pitfall here: the static login page still returns a 200 OK even when the backend authentication service breaks. If monitoring only checks HTTP status codes, the system will show fully green while all users fail to log in.

The team designed step-by-step synthetic monitoring for the login workflow: simulate visiting the login page, enter random credentials and submit the form. The probe treats the system returning the prompt “invalid username or password” as proof of healthy operation. Only when the authentication service runs normally will this business-specific error message appear. One single probe verifies three components at once: page accessibility, end-to-end login connectivity, and authentication service availability.

This design turns negative error messages into positive health evidence. A missing error prompt is far more alarming than the error itself. This validation logic applies widely to login chains for finance companies, banks and securities firms offering corporate online banking services.

Rollout Methodology: From Monitoring Checklists to Auditable Ledgers

The three scenarios follow a unified four-step rollout framework, independent of specific vendor environments and adaptable to all finance companies.

Step 1: Select monitoring targets from a business perspective Do not configure probes for all 100+ functional modules. First identify which page outages will immediately create business trouble tickets. The number 19 comes from strict filtering, not an upper configuration limit.

Step 2: Define clear validation criteria for each probe Differentiate between simple connectivity and business accuracy: use status code checks for basic availability, content keyword matching for data validation, and multi-step scripting for interactive workflows. The closer the criteria align with real business expectations, the fewer false alerts you will receive.

Step 3: Clarify alert rules and accountability boundaries Define the number of consecutive failures that trigger alerts, assign recipients, and specify responsible teams during configuration. Avoid situations where alerts are issued but no team takes ownership.

Step 4: Document all settings into a formal ledger Record monitoring targets, validation rules, alert thresholds and responsible parties line by line. This makes the entire synthetic monitoring system auditable, reviewable and transferable between teams.

The biggest barrier to implementation is not technical configuration, but translating business requirements into probe rules. This requires close collaboration between operations and business departments — the most worthwhile investment when building business-level observability.

Industry Value: Turn Business Status into Verifiable, Auditable Facts

For finance companies, the value of observability projects must be measured against end-of-day batch jobs, member entity transaction requests, and daily on-call arrangements.

✅ Earlier fault detection Outages on key pages are now captured within minutes via proactive probes, instead of waiting 30+ minutes for user complaints. Longer response windows are secured, as demonstrated by the 5 a.m. alert case.

✅ Proactive on-call operations On-call engineers no longer passively answer support calls and troubleshoot vague user reports. They receive clear alerts with pre-defined validation criteria and can jump straight into incident handling. This shifts operations from reactive support to proactive fault response, easing workload pressure and improving response quality.

✅ Verifiable business logic Monitoring evolves from checking “whether the API is reachable” to validating “whether query results are accurate”. Real-time balance freshness and login chain health are backed by tangible technical evidence instead of retrospective user feedback.

✅ Accurate impact assessment The auditable monitoring ledger ties every alert to clear accountability. When failures occur, teams can quickly tell whether the issue affects only a single page or the entire network link, narrowing down troubleshooting scope significantly.

✅ Reusable operational experience Monitoring checklists, validation logic and threshold settings are saved on the platform. New page rollouts and system launches can reuse existing templates without building monitoring rules from scratch.

✅ Synergy with legacy monitoring systems Synthetic monitoring does not replace existing infrastructure monitoring; it fills the gap at the business layer. Combined with link tracing, scheduled task monitoring and deep component monitoring, the four-tier system enables accurate fault localization at the correct layer, eliminating the need to start every troubleshooting process from server hardware checks.

Infrastructure monitoring answers: Is the system still alive? Business monitoring answers: Can business operations still run?

For finance companies, the second question is the critical line to defend.

Start with key web pages and shift fault detection ahead of user complaints. This implementation requires no complex system transformation and hinges on three core actions: select the right monitoring targets, set accurate validation criteria, and route alerts to the right people.

Ensure member entities can pull bank statements, verify account balances and log into systems without interruption. Free on-call engineers from endless user calls so they only focus on handling system alerts. This is the tangible business value of page-level synthetic monitoring for the financial industry, and a proven path for finance companies to shift monitoring from an infrastructure-centric view to a business-centric view.