This page covers all of the features of the Monitor view in Appian Designer.
To access this view, click Monitor in the navigation pane at the environment level or in an application.
When you access this view at the environment level, it contains information about deployments in the current environment. When you access the view from within an application, it contains information about deployments in the individual application.
The Monitor view helps you keep an eye on health and activity indicators for your applications.
The Monitor view consists of a header bar, navigation pane, and the following tabs:
The Health Dashboard tab provides an at-a-glance overview of the health of your environment or application. It includes both runtime and design-time information, and surfaces related metrics and key performance indicators.
The dashboard is composed of three sections.
Note: Only objects for which a developer has at least Viewer permissions are reflected in the dashboard's various summary cards and displayed in its Appian Design Guidance grid. The only exception to this is the Process Activity section, which displays processes that a developer has Initiator or higher permissions to.
The annotated screenshot above and descriptions below define the metrics and information displayed on the Health Dashboard tab.
Note: Process models must be published in order for their design guidance to appear on the Health Dashboard.
The Process Activity tab shows a list of all process instances related to your environment or application that are currently on the system. By default, the processes list displays only processes that have started in the last 7 days and have not been archived. See Process Activity filters to change the status and time range.
Note: Developers must have at least Initiator permissions to processes in order to see them on this monitoring tab.
The annotated screenshot and descriptions below define the features and metrics displayed on the Process Activity tab.
Note: Currently, archived processes are available under the Process Activity tab for all new Appian Cloud sites in Appian 21.1 or later versions and will be enabled on existing Appian Cloud sites via a phased approach.
Errors: Unresolved errors associated with the process. Hyperlinked to open a Process Errors dialog that displays the process' error message and its details.
A banner above the processes list notifies developers about all of the unresolved errors which have occurred in the last 24 hours. Clicking on View all process errors opens a dialog (see image below) which provides detailed information about each process error and gives developers the ability to filter errors.
By default, the process errors list in the dialog only displays the unresolved errors that require attention. Resolved errors (including their resolution datetime and the user who resolved them) can be viewed by clicking the Show resolved errors checkbox in the dialog's upper right-hand corner.
The left-hand pane of the Process Activity tab contains search and filter options.
Developers can filter listed processes in the following ways:
When a process is selected, options will appear in the toolbar above the processes list. Multiple processes can be selected at once in order to perform operations in bulk, but note that not all options support bulk operations.
The following options are available in the toolbar:
In addition to being able to select and perform operations on multiple processes on a single page, developers can select and perform operations on processes across multiple pages. To do so, select all processes on the current page (A). A grey banner will then appear (B) directly below the toolbar with the option to select all processes that match the current filter criteria, for up to 10,000 processes.
In addition to the search and filter options provided on the left-hand pane of the Process Activity tab, there is a link to the customizable report. Clicking this link opens the All Processes process report in a new tab. Changes to the All Processes report do not affect the Process Activity tab in Appian Designer and vice versa. This report does not allow you to view process errors.
The Process Model Metrics tab shows metrics related to the memory usage of process models on the system. Only process models with process instances on the system are shown in this report. By default, process models are sorted by those consuming the most to least total memory.
Process memory is expressed in AMUs. This process memory calculation runs in the background and is not real-time.
Note: Developers are only able to view metrics on this tab for process models that they have at least Viewer permissions to.
The annotated screenshot and descriptions below define the features and metrics displayed on the Process Model Metrics tab.
Note: Developers must have at least Viewer permissions to process models in the current environment in order to view their process model metrics from another environment.
[deleted]
.Status Icon: A quick visual indicator of each process model's memory usage based on the current total calculated AMU of all active instances of that model (see #5 below). Possible statuses include:
Icon | Size Status |
---|---|
Displayed for models whose current total calculated size is less than 100,000 AMU. The memory usage of this model's instances is generally considered low. | |
Displayed for models whose current total calculated size is between 100,000 and 1,000,000 AMU. The memory usage of this model's instances could potentially affect the system. | |
Displayed for process models whose current total calculated size is greater than 1,000,000 AMU. The memory usage of this model's instances is high. |
Note: The qualifications of Low, Medium, and High memory usage are based on average resource allocation and usage. Your systems and expected usage may not reflect these boundaries. If you have concerns, contact your system administrator.
It is important to look at all of the various dimensions available in the Process Model Metrics tab, when trying to optimize the performance of your process models and their instances on your system. While Total Size is a good initial indicator of potentially memory intensive process models, it is often necessary to look beyond just this value on its own.
For process models using a significant amount of memory:
If you're updating the design of a process model, consider the following factors which impact the memory footprint of your process models and their instances:
The Record Response Times tab allows you to monitor the performance of your record interfaces (both record lists and record views), and identify those with the slowest interactions.
This tab displays the top ten slowest response times for each record list or view, including details about when the slowest response times occurred and who executed them. For each of these response times, you can check the Performance tab to help you identify why a specific interaction might not be performant (see #9 below).
Note: Developers must have at least Viewer permissions to records in order to view their response times on this tab.
The annotated screenshot and descriptions below define the features and metrics displayed in the Record Response Times tab.
Health Icon: A quick visual indicator of each record interface's response time health, based on the average response times that were collected for the interface over the last 30 days. Possible statuses include:
Health Icon | Response Time Status |
---|---|
Displays when the response times for this record are low. | |
Displays when the response times for this record could potentially affect the system. Consider reviewing the record's performance views (#9 below) and design to reduce its overall latency. | |
Displays when the response times for this record are high. Review the record's performance views (#9 below) and designs to reduce its overall latency. |
Note: Developers must have at least Viewer permissions to the selected record interface in order to delete the response time history.
Note: This toggle is turned on by default. Turning metric collection off may improve your overall system performance.
When record UIs have high average response times, use their performance tab (#9 above) to troubleshoot and ensure that all of their rules and queries are performant.
The Record Sync Status tab displays status information for all record types with sync enabled. This includes the source type, sync status, time of the last sync, and the total rows synced for each record type.
From this tab, you can easily perform cross-environment monitoring for all synced record types that you have access to view by switching between your connected environments, both local and remote. Drill down into a specific record type to view its sync history and any errors or warnings that occurred during the course of the sync activity.
The annotated screenshot provides a description of each grid column on the Record Sync Status tab.
Last Sync Status: The current sync status of the record type. Possible statuses include:
Icon | Status | Meaning |
---|---|---|
Running | A manual or scheduled sync is taking place, the record type is saving, or the record type is being imported to the environment. | |
Canceling | A manual or scheduled sync is being canceled. | |
Completed | A manual or scheduled sync, record type save, or record type import has successfully completed. | |
Failed | An error occurred while attempting to sync the record type and the record type is unavailable. Click the link next to the icon to open the Sync Alerts dialog. | |
Failed and Skipped | An error occurred while attempting to sync the record type, but the record type is still available. Since this sync was skipped, queries will return data from the most recent successful sync. Click the link next to the icon to open the Sync Alerts dialog. | |
Failed and Retrying | The sync initially failed and the system will retry a few times before failing. After failing, the record type will be unavailable. | |
Canceled | A manual or scheduled sync was canceled. The record type returns to the previous sync status. If the previous sync status was Failed, then the record data will be unavailable. Click the link next to the icon to open the Sync Alerts dialog. | |
Approaching Limit | The record type was able to sync but it's approaching the row limit. | |
Limit Reached | The record type was able to sync but the row limit has been reached. |
As an administrator, you need a way to restart a sync for a record type in a remote environment. You also need a way to quickly view the statuses, sync history, and errors associated with your synced record types across multiple environments. This visibility allows you to easily resolve issues that cause your syncs to fail.
The Select Another Environment button on the Record Sync Status page opens the Select Environment dialog, which lists all of your local and remote connected environments.
After you select a specific environment from the list, click VIEW RECORD SYNC STATUS to switch to the select environment and view the statuses for all of the synced record types deployed in the selected environment.
Note: You can view the status for synced record types if they have been deployed to an environment that allows a connection from Appian to the selected environment. See Managing Environments for more information.
The Record Sync Status tab will now show the sync statuses for all record types deployed in the selected environment only. In order to view synced records in a local environment, developers must have at least Viewer permissions to the record types. When connecting to a remote environment, developers only have access to the record types they have access to in the local environment.
Also note that only users with edit access to the record type in the selected environment can start a sync.
When the sync status is Failed, Failed and Skipped, or Canceled, you can click on the link in the Sync Status column to open the Record Type Sync Alerts dialog. This dialog provides more information and details about the failed or canceled sync.
Depending on the type of alert, the dialog can contain the following properties:
Property | Description |
---|---|
Record Type | A link to the record type. |
Source Type | The source type of the record type. Possible values are Database , Salesforce or Web Service . |
Initiated by | Who started the sync. Depending on the type of sync, this value can be System , Administrator , or the username of the user who started the sync. |
Alert | The cause of the alert. |
Caused By | Any additional details provided by the source to help troubleshoot the error. |
Details | A link to the process instance that updated the source and up to five primary keys from the source rows that were updated by the write operation, but not synced in Appian. This property is only displayed when a sync fails on a record type that uses a database table or Salesforce object as the source. |
For information on resolving errors with your sync, see Troubleshooting Syncs.
When you click into a specific record type in the grid list from the Record Sync Status tab, you are directed to the Sync History grid for the selected record type. This page shows information about the previous and currently running syncs for the record type.
You can also access this Sync History grid from the Data Sync tab in record type object.
Like the Record Sync Status tab, you can access any errors for your record type's syncs from within its history.
The annotated screenshot and descriptions below define the buttons and grid columns displayed in the Sync History grid page.
Status: The sync status of the record type. If the status is Failed
or Failed and Skipped
, you can click the link to open the Sync Alerts dialog. Possible statuses include:
Icon | Status | Meaning |
---|---|---|
Running | A manual or scheduled sync is taking place, the record type is saving, or the record type is being imported to the environment. | |
Canceling | A manual or scheduled sync is being canceled. | |
Completed | A manual or scheduled sync, record type save, or record type import has successfully completed. | |
Failed | An error occurred while attempting to sync the record type and the record type is unavailable. Click the link next to the icon to open the Sync Alerts dialog. | |
Failed and Skipped | An error occurred while attempting to sync the record type, but the record type is still available. Since this sync was skipped, queries will return data from the most recent successful sync. Click the link next to the icon to open the Sync Alerts dialog. | |
Failed and Retrying | The sync initially failed and the system will retry a few times before failing. After failing, the record type will be unavailable. | |
Canceled | A manual or scheduled sync was canceled. The record type returns to the previous sync status. If the previous sync status was Failed, then the record data will be unavailable. Click the link next to the icon to open the Sync Alerts dialog. | |
Approaching Limit | The record type was able to sync but it's approaching the row limit. | |
Limit Reached | The record type was able to sync but the row limit has been reached. |
System
, Administrator
, or the username of the user who started the sync. Only users with access to edit the record type will be able to view the Initiated By column.
You can sort the results in the Sync History grid by Start Time, End Time, Duration, Total Synced Records, and Total Source Rows.
The Query Performance tab centralizes key information about each query to your record types. This allows you to quickly identify which parts of your application may experience slow queries.
This summary includes the names of users and design objects involved in running the queries, as well as critical information from system logs throughout your environment.
This tab captures queries that are run by developers in Appian Designer and by users interacting with your applications.
To understand the overall performance of an interface evaluation, see the Performance view for the interface.
The annotated screenshot provides a description of all key elements on the Query Performance tab:
Capture Query Data option: By default, Appian does not capture information for display in the Query Performance tab. Use the Capture Query Performance option to enable the capture of information about queries to record types in your environment.
Tip: To avoid potential performance impacts in production environments, only enable this setting if you are actively troubleshooting.
Grid: This grid contains the key details about your queries. Columns include:
Column | Description |
---|---|
Query UID | A unique identifier for the query. Click the link to see an expression that illustrates the record types, fields, filters, and functions used in the query. |
Query Start Time | The date and time at which the query started running. |
Query Execution Time | The time (in milliseconds) that the query took to wait for resources and run. |
Query Wait Time | The time (in milliseconds) the query waited for resources. |
Started By | The username of the user who ran the query. |
Evaluation ID | A unique identifier for a single evaluation of the interface or expression rule used to run the query. A single evaluation of an interface or expression rule can include multiple queries, which will be listed separately in this table. Use this ID to evaluate the cumulative performance of all queries in an interface or expression rule. |
Interface | The interface where the user ran the query. This column may contain an expression rule if the query was run from a process model, or may be blank if the query was run directly from a record view or record list. Click this link to open the identified design object. |
Expression Rule | The design object used to run the query, usually an expression rule. This column may be blank if the query was run directly from a record view or record list. Click this link to open the identified design object. |
Record Type | The record type used in the query. Click this link to open the identified record type object. |
Component | The component used to run the query. In some instances, this column may contain a function, record view, or record action, depending on how the interface or expression rule is configured. |
Error Code | The Appian error code. This column is only populated if the query evaluation encounters an error. Learn more about error codes for a!queryRecordType function. |
The Portal Monitoring tab allows you to view key metrics and details that are vital to understanding how users are interacting with your portals and what issues they may be experiencing. Regularly monitoring these metrics alerts you to any potential issues related to response times or availability and helps you deliver exceptional user experiences while maintaining high operational standards.
To view metrics for other connected environments, use the icon to switch between environments. This is especially helpful to view metrics for portals in a production environment without requiring access to the environment.
The annotated screenshot provides a description of all key elements on the Portal Monitoring tab. For more information about using the Portal Monitoring tab to troubleshoot issues in a portal, see Troubleshooting a Portal.
Note: You must have at least Viewer permissions to portals in the current environment in order to view their metrics from another environment.
Published
, Not Published
, and Published with errors
. By default, all statuses display.Last 24 Hours
, Last 7 Days
, Last 30 Days
, Last 90 Days
. The default time period is Last 7 Days
.Published
, Not published
, Published with errors
.While the goal is designing and publishing high-quality portals that provide an issue-free user experience, problems can occasionally occur. These metrics are meant to alert you when problems arise with the speed or availability of your portals.
A better understanding of these monitoring metrics will help you understand what's happening and where to begin troubleshooting if you see longer than expected latency times or high error rate percentages on this tab.
A simple way to think about latency is as a measure of the "waiting time" between when you do something and when you see a result or get some sort of feedback from the action you've taken.
In the context of portals, latency could be a measure of how long it takes for:
The latency metrics displayed on the Portal Monitoring tab represent the delay between all traffic requests and the portal server's response to those requests.
A traffic request occurs anytime a page loads or a user interacts with the portal, like when they click a button. Depending on the portal and the time period, traffic requests can number in the hundreds or even thousands.
The number of traffic requests also provides useful context for error rate and latency metrics. For example, a 50% Error Rate may not be as worrisome over a handful or traffic requests and a double-digit Error Count may not be reason for alarm if the portal has received thousands of traffic requests for a given time period.
Keeping an eye on traffic requests helps you ensure your portals can handle high user demand while remaining both available and performant.
Traffic requests have the potential to result in an error. The error rate is a percentage value that represents the proportion of traffic requests that resulted in an error.
A high error rate can be an indicator that users are encountering serious problems when they interact with a portal. A icon displays next to the error count when a user has encountered an error within the last 24 hours.
See Troubleshooting a Portal for more information on how to act on these metrics, including how to troubleshoot errors and how to troubleshoot latency issues.
From the Portal Monitoring tab, you can view a Portal Errors grid to help determine which objects could be causing the errors and where to look next for more information. You can also download the Portal Error Log, which can be accessed above the grid.
In Appian Cloud environments where enhanced portal logs aren't available, you won't be able to click the number in the Error Count column to view the Portal Errors grid. Instead, download the Portal Server Log to troubleshoot errors.
To view error details from the Portals Monitoring tab:
Monitor View