Database availability and sessions
Inspect connectivity, connections, sessions and errors with engine, instance, host and site context.
Database health & service checks
Test service availability from defined locations.
AmrudAi’s documented synthetic monitoring scope tests a defined service result from an authorized location, using explicit assertions and execution limits. HTTP/API, DNS, TCP and TLS evidence helps distinguish failure stages before investigation follows database or infrastructure dependencies. Source health and corroborating observations remain essential; browser journeys require separately qualified release and execution support.
Choose the operational question
What does a failed synthetic check actually establish?
It establishes what a defined test observed from its authorized source, at a recorded time, under its configured assertions. AmrudAi’s documented approach preserves that scope before comparing other vantages and dependencies. Check execution health and the failing stage first; a DNS, TLS or credential problem does not automatically establish an application-wide outage.
| Define | Record | Confirm before escalating |
|---|---|---|
| Target and assertion | Protocol, endpoint, permitted method and expected status or content. | The assertion reflects the service outcome you intend to measure. |
| Vantage and execution | Source location, credentials, schedule, budget and freshness. | The collector could execute the check and reach its dependencies. |
| Failure stage | Available DNS, connection, TLS, response and assertion evidence. | Independent observations corroborate the affected scope. |
Continue with: Database performance investigation · Service measurement and qualified incidents · Certificate monitoring .
The application experience
Database evidence behind a service check
See the complete workspace. Enlarge any image to inspect its panels, navigation and evidence at actual size.
Database Performance & Wait Analysis — illustrative product view with sample data. Illustrative product view · Sample data
Connect slow queries, lock chains, replication and host resources to a database service. The capability in detail
Connect database health to the service check.
Storage and replication
Bring database capacity, storage conditions and replication state into the same view as the infrastructure they depend on.
Locks, waits and performance
Inspect engine-exposed lock, wait, latency and query-health evidence. Retain source permissions, sampling and collection quality when relating the observations to host, storage and service conditions.
Controlled query monitors
Use governed query-monitor definitions and scoped credentials for approved database checks. Arbitrary dangerous SQL is not enabled by default.
Database engine coverage
Connect PostgreSQL, Microsoft SQL Server, Oracle, MySQL/MariaDB, SAP HANA, MongoDB, ClickHouse and OpenSearch to database performance, host, storage and service evidence through their technology profiles.
Structured network and service tests
Define ICMP, TCP, DNS, HTTP/HTTPS, REST API and TLS/certificate checks, with optional UDP only where its success semantics are well defined.
HTTP and API assertions
Configure methods, headers, authentication, bodies, expected status and body/header validation. Review DNS, connection, TLS and response timing where available.
Multi-location experience
Compare results from authorized locations and vantages. Keep the test source, execution time, failure stage and data quality visible.
Certificate health
Review expiry, validity, chain, hostname mismatch and relevant TLS-policy conditions before they become unexplained service failures.
Shared infrastructure services
Correlate DNS responses and record validation, DHCP scope/lease state, NTP sync and supported AD/LDAP/Kerberos or RADIUS/TACACS evidence.
Service-assurance evidence
Tie active checks and database observations to service dependencies, qualified incidents, maintenance exclusions and SLA/SLO analysis.
Specialist depth when qualified
The extended scope adds bounded database fingerprints, blocking/deadlocks, regression/plan evidence and browser journey steps with assertions and timing after their separate certification gates.
From information to action
A connected operational workflow.
- 01
Define success
Choose the database or structured test and specify the valid result.
- 02
Verify permissions and vantage
Test the actual source path, credentials and required capability.
- 03
Inspect the failing layer
Separate DNS, transport, TLS, HTTP, database, host and dependency evidence.
- 04
Connect to assurance
Attach the verified result to the incident and the appropriate service-measurement policy.
Database and service checks
Fit the way your team operates.
Combine structured HTTP/API and shared-service checks with database evidence. Browser journeys require separately qualified release, runtime and concurrency scope.
- Investigate supported database engines through connection health, resource pressure, query-performance evidence and the dependencies beneath the database.
- Where the selected release and execution profile have passed the required certification gates, define browser journey steps, assertions, credentials, locations and collection budgets.
- Import cURL definitions as structured monitors with controlled methods and parameters, without granting shell execution.
- Use scoped, bounded database queries and evidence-backed recommendations. Database changes require the appropriate operational authorization.
What can active service checks establish?
Can we monitor a custom API?
Yes. Structured HTTP/API monitors and API Studio mappings support custom services with defined authentication, response schemas, safe methods, pagination, rate limits and success assertions.
Can we run arbitrary SQL?
Query monitors use scoped credentials, controlled definitions and bounded execution. Operators select approved queries and permissions appropriate to the database; monitoring access does not grant unrestricted modification rights.
Can we monitor a browser journey?
Browser journeys belong to a separately qualified release and execution profile. Confirm the required certification, supported steps, assertions, credentials, locations and concurrency limits before relying on this workflow. Where that scope is available, journey evidence can be related to service, host, database and network observations.
Does a failed synthetic test prove the application is down?
A result proves what that test observed from that location. Qualification must consider source health, independent vantages and available dependencies before making a broader service conclusion.
See the workflow in your environment.
Explore the technology, service dependencies and operating requirements that matter to your team.