Skip to content
Sign in
  • There are no suggestions because the search field is empty.

GSAPI QueryMonitor

Create automated alerts based on SQL queries to monitor interfaces, charging processes, and customer-specific logic.

Version: 2026_1
Audience: Consultants and advanced customers needing automated monitoring
Purpose: Explain how QueryMonitor works, how to build alert queries, how to configure triggers, and how notifications are generated.

1. Overview

QueryMonitor allows you to create SQL‑based monitoring rules that automatically detect problematic situations in data or integrations.
A QueryMonitor entry:

  • runs a SQL query according to a schedule or trigger
  • evaluates the result as OK, Warning, or Alert
  • sends the notification to configured recipients
  • optionally shows guidance via checklists

This tool is especially useful for detecting:

  • missing or stalled interface imports
  • incorrect aggregation states
  • unmapped usage
  • data that should have progressed to a later processing stage
  • other customer‑specific conditions

QueryMonitor is found under System Setup.


Figure 1: QueryMonitor entries in System Setup

2. Creating a QueryMonitor Entry

Each QueryMonitor entry consists of:

  • SQL Query — must return JSON containing at least Alert or Warning
  • SchedulePattern — defines when the query runs
  • MonitoringType — defines optional triggers based on interface executions
  • Recipients — email destinations
  • Checklist — optional guidance for resolving issues
  • Connection — database connection to execute the query

The QueryMonitor entry dialog contains numbered fields corresponding to these configuration items. [GSAPI_Cont...ansactions | Word]

Figure 2: Configuration fields of a QueryMonitor entry

3. Writing the SQL Query

The SQL query must return a JSON object with at least one of these fields:

  • Alert
  • Warning

Optionally, the query may include:

  • InformationList — array with additional context
  • Custom fields describing the issue

Example format

 SELECT
    'Incredible Alert Example' AS Alert,
    (SELECT TOP 10 * FROM dbo.Currency FOR JSON PATH) AS InformationList
FOR JSON PATH, WITHOUT_ARRAY_WRAPPER

Important rules

  • Field names are case-sensitive
  • If the query returns nothing, the monitor interprets it as OK
  • If triggered by an interface (MonitoringType), an alert appears after execution

4. Schedule, Triggers, and Execution

QueryMonitor can run:

  • on a timed schedule (cron-like pattern)
  • when a specific interface executes (via MonitoringType)

The NextRuntime field shows when the query will next execute.
Alert messages include references to MonitoringType when applicable. 


Figure 3: Alert message with MonitoringType reference (numbers in red not referenced explicitly)

5. Notification Emails & Checklists

If an alert is raised:

  • an email is sent to recipients
  • the email contains the JSON alert message
  • if a checklist is defined, it is included as guidance

Checklists help guide customers and internal teams through known resolution steps.


Figure 4: Example of an alert email including a checklist

6. Interface-Executed Triggers

If MonitoringType is linked to an interface:

  • executing that interface can trigger QueryMonitor immediately
  • issues appear in the notification panel
  • an email follows shortly after

This is useful when monitoring interface-specific issues, such as:

  • failed enrichments
  • missing reference data
  • incomplete aggregation progression
  • stalled import states


Figure 5: Interface-executed trigger showing alert in notification panel

7. Summary

Element Description
SQL Query Returns JSON containing Alert, Warning, or both
Trigger Scheduled or interface-executed
Checklist Optional diagnostic instructions
Recipients Email addresses or <author> tag
MonitoringType Adds triggers for interface executions
Output Email + UI notification

QueryMonitor is a flexible mechanism for detecting issues early before they affect billing or customer experience.

8. Consultant Notes (Advanced)

SQL Requirements

  • The query must return JSON via FOR JSON PATH.
  • Use WITHOUT_ARRAY_WRAPPER for single-object responses.

Choosing MonitoringType

  • Link to critical interfaces to catch failures automatically.
  • Use separate monitors for separate interface flows to avoid noise.

ActionId customization

  • Default ActionId is 1400.
  • Custom ActionIds can be used when building advanced procedures.

Connection Strings

  • Default is the local database.
  • For cross-database monitoring, additional connections can be added in settings.

Example customer scenarios

  • Monitoring orphan transactions in usage imports
  • Detecting stalled aggregation states (e.g., t_id not reaching 4)
  • Ensuring master data references exist
  • Checking organization resolution via businessId fields