Diagnose failed app reloads with AI and notify your team on Slack using Qlik Automate

[AfeefaTk]

This article gives an overview of how to analyse failed app reloads with OpenAI using Qlik Automate, which is now available as a template.

This template is triggered when a Qlik Cloud app reload fails. It then analyzes the reload error with OpenAI and sends a Slack message with the app, space, reload details, and AI diagnosis. Session app and data preparation reloads are filtered out to focus on user-created script issues, keeping your alerts relevant and actionable.

This template is a good starting point if you want to:

• Automatically detect when an analytics app reload fails
• Get an instant AI-powered analysis of the likely root cause
• Notify your team in Slack with all the context they need
• Keep noise low by filtering out session app and data preparation reloads
• Maintain a clear automation run history through readable run titles

The template is available on the template picker. You can find it by navigating to Add new -> New automation -> Search templates, searching for Diagnose failed app reloads with AI and notify your team on Slack in the search bar, and clicking the Use template option.

You will find a version of this automation attached to this article: "Diagnose-failed-app-reloads-with -AI-and-notify-your-team-on-Slack.json".

Content

• What this template does
• Before you start
• Step-by-step walkthrough
• Step 1: App Reload Finished (Webhook event)
• Step 2: Condition: skip session apps
• Step 3: Get Current Tenant Info
• Step 4: Condition: check if a space exists
• Step 5: Get User
• Step 6: OpenAI: Chat Completion Message (prompt builder)
• Step 7: Variable: chatList (message formatter)
• Step 8: OpenAI Chat Completion (AI call)
• Step 9: Condition 3, check if the AI response is too long
• Step 10: Send the Slack Message
• Step 11: Output 3 (run output display)
• Step 12: Update Run Title and Update Run Title 2
• Customization ideas
• Tips for new users
• Troubleshooting
• Summary

What this template does

When an analytics app reload fails, the automation:

1. Triggers on the App Reload Finished webhook event, filtered to analytics app reload errors only
2. Ignores session app reloads
3. Looks up tenant, user, and space details
4. Sends the reload error details to OpenAI for analysis
5. Posts the result to Slack
6. Updates the run title so the automation run history is easier to scan

The Slack message includes:

• The app name with a direct link to the app
• The app reload ID for reference
• Space name and space type
• The time the reload failed
• Reload duration
• An Error code or codes
• The AI-generated diagnosis and suggested next steps
  
  

Before you start

Before using this template, make sure you have access to:

• Qlik Cloud Tenant with permission to create and run automations
• The OpenAI connection configured in your tenant
• The Slack connection configured in your tenant

Step-by-step walkthrough

Step 1: App Reload Finished (Webhook event)

This is the first block in the automation. It acts as the listener that starts the entire workflow.

How it works:

The block runs in webhook mode and listens for the App Reload Finished webhook event from the Qlik Cloud Services connector. The template uses an App ID guard in the event filter to prevent unnecessary webhook triggers: (App Ids eq "Specify_Your_App_Id_Here")

What you need to configure:

Event Filter: Pre-set to Reload status (A) as Failed (error) and Usage (B) as Analytics. Replace Specify_Your_App_Id_Here in the App Ids (C) parameter with your actual app Id during development.

When moving to production, either:

• Keep the App Ids filter to monitor only selected critical app(s)
• Keep the Space Ids filter to monitor apps that reside in specific space(s)
• Remove the App Ids and Space Ids clause to monitor all analytics apps in scope

Step 2: Condition: skip session apps

This block provides a second layer of filtering, specifically for session apps.

How it works:

Even though the App Reload Finished webhook event filter only includes analytics app reloads, session apps can still slip through because they share the Analytics usage type. This condition checks the app ID for the SessionApp_ prefix. 

Session apps are temporary apps, primarily used by background system processes rather than front-end user consumption, so including them usually adds noise and low-value alerts.

Only include session app events if you intentionally create session apps through Qlik Cloud APIs. In that case, you should filter on the actor so that only your own generated events are processed.

Yes branch:

If the app is a session app, the automation stops early. The run title is updated to Analysis skipped (SessionApp) so the automation history clearly shows why no alert was sent.

No branch:

If the app is not a session app, the automation continues to the next blocks, where it gathers tenant, space, and user details before sending the failure analysis to OpenAI and posting the result to Slack.

What you need to configure:

• Nothing. This condition is pre-configured and requires no changes.
• Optional: If your use case depends on API-generated session apps, remove this exclusion and add an actor-based filter to avoid unrelated system events.

Step 3: Get Current Tenant Info

This block retrieves the hostname and other details about your Qlik Cloud tenant.

How it works:

The tenant hostname is later used to build a direct link to the failed app in the Slack message. Without this step, the link would be incomplete.

Step 4: Condition: check if a space exists

This block checks whether the failed analytics app reload came from an app that belongs to a space.

How it works:

It checks whether the space ID in the event payload is empty.

Yes branch:

If a space exists, the automation continues to the Get Space block. This block retrieves the name and type of the space where the analytics app lives. It uses the space ID from the App Reload Finished webhook event to look up the full space details, and it's stored in an object variable. The space name and type are included in the Slack message so your team immediately knows where the failed app is located.

No branch:

If no space exists, which means the app resides in the user's personal space, the automation creates a default object with the name Personal and type personal. This ensures the Slack message still has a space value to display, even when the app is in the user’s personal space.

What you need to configure:

Nothing. This condition is pre-configured and requires no changes.

Step 5: Get User

This block retrieves details about the user whose app reload failed.

How it works:

It uses the user ID from the App Reload Finished webhook event to look up user details. This information can be referenced in the Slack message and is useful if you want to escalate directly to the app owner or expand the notification with owner's contact information later.

Step 6: OpenAI: Chat Completion Message (prompt builder)

This block constructs the prompt that is sent to OpenAI.

How it works:

It formats the app reload error details from the App Reload Finished webhook event payload into a structured message and passes it to the OpenAI Chat Completion block.

The pre-written prompt instructs OpenAI to act as a senior Qlik Cloud Analytics engineer, identify the root cause of the app load script error, explain why it happened, and suggest the exact changes needed to fix it. Responses are capped at 800 characters and formatted as plain numbered paragraphs so they fit cleanly into a Slack message.

What you need to configure:

1. Connection: Connect this block to your OpenAI connection.
2. Content: The prompt is pre-written and ready to use. You can edit it if you want a different tone, more or less detail, or a different response format.
3. Role (required parameter): Set the role value (for example, assistant). This is required for a valid chat message payload.

   The role field is empty by default. The automation will fail at this step if you do not provide a role before running.

4. Other optional parameters: Leave the optional fields (Name, Functional Call Arguments, Function Call Name) empty unless you have a specific advanced use case.
   
   

Step 7: Variable: chatList (message formatter)

This block bridges the prompt builder and the OpenAI Chat Completion block.

How it works: 

The OpenAI Chat Completion block expects messages to be passed as a list, not a single object. This block first empties the chatList variable to make sure there is no leftover data from a previous run, then adds the response from the Chat Completion Message block as a new item in the list. The result is a properly formatted list that can be sent directly to the Chat Completion block.

What you need to configure:

Nothing. This block is pre-configured and works automatically based on the output of the previous step.

Step 8: OpenAI Chat Completion (AI call)

This block sends the prompt to OpenAI and receives the analysis response.

How it works: 

It calls the OpenAI Chat Completion API using the message built in the previous step.

The token limit is pre-set to 300 to keep responses concise. It prevents the model from rambling, helps cap output length to reduce cost, and remains bounded by the selected model's own architectural limits. The model field is intentionally left blank so you can choose the model that suits your subscription.

We tested this template with the gpt-5.4-mini model, and it performed very well for reload-failure diagnosis. In most cases, lower-cost models are generally very effective at diagnosing.

What you need to configure:

1. Connection: Make sure this block is connected to your OpenAI connection.
2. Model (required parameter): Use the do lookup functionality to select the model from the options available for you, or enter the name of the model you want to use.

   The model field is empty by default. The automation will fail at this step if you do not provide a model name before running.

3. Other optional parameters: Keep defaults unless you need specific tuning.
   
   

Step 9: Condition 3, check if the AI response is too long

This block checks whether the AI response fits within the Slack message size limit before sending.

How it works:

It measures the character length of the OpenAI response. If the response is 2800 characters or more, the message is too long to be posted cleanly in Slack, so the automation takes a fallback path.

Yes branch, response is too long (≥ 2800 characters):

The output variable is set to a fallback message: "Generated message was too long. Refer to [link] for full response."

The link points directly to this automation run in the history page so the team can still access the full AI diagnosis.

No branch, response fits (< 2800 characters):

The output variable is set to the full AI response from OpenAI. This value is then used in the Slack message in the next step.

What you need to configure:

Nothing. This condition is pre-configured. You can adjust the 2800-character threshold if needed.

Step 10: Send the Slack Message

This block posts the App Reload failure notification along with AI diagnosis to your Slack channel.

How it works:

It formats all collected details into a single Slack message. The message contains:

• A red circle emoji as a visual alert indicator
• The app name as a clickable link to the app in Qlik Cloud
• The app reload ID
• The space name, space type, and space ID
• The time the reload failed
• The reload duration in seconds
• The error code or codes
• The AI diagnosis from the output variable — either the full response or the fallback link, depending on which branch was taken in Step 9

What you need to configure:

1. Connection: Connect this block to your Slack connection.
2. Channel (required parameter): Use the do lookup functionality to find the ID of the Slack channel or directly enter the ID of the Slack channel where alerts should be posted.

   The channel field is empty by default. The automation will fail at this step if you do not provide a channel before running.

Step 11: Output 3 (run output display)

This block writes the full Slack message content to the automation run output so it is visible directly in the Output section of the automation run history.

How it works:

It captures and displays the exact same formatted message that was sent to Slack — including the app link, reload ID, space details, error code, and AI diagnosis. This means you can review what was sent without opening Slack, which is useful when debugging or auditing past runs. 

Step 12: Update Run Title and Update Run Title 2

These two blocks make automation run history easy to scan without opening every run.

How it works:

• Update Run Title is used on the main processing path (non-session apps). It sets a clear run title like:
  
  Assessed {app name} ({app id})
  
  This tells you the reload failure was analyzed and an alert flow was executed.
  
  
• Update Run Title 2 is used on the session-app skip path. It sets:
  
  Analysis skipped (SessionApp)
  
  This tells you the run intentionally exited early and did not send the full analysis flow.

Why this matters:

• Improves observability in run history
• Makes triage faster for support teams
• Distinguishes successful analysis runs from intentionally skipped runs

What you need to configure:

• Nothing. Both blocks are pre-configured.
• Optional: You can customize the title text to include the app owner or severity labels.

Customization ideas

You can modify this automation to match your specific requirement:

• Change the destination channel: send alerts to a different communication channel, like Microsoft Teams
• Add escalation steps: end email or Microsoft Teams alerts for critical apps or production spaces
• Adjust the AI prompt: make the response shorter, more technical, or tailored to your load script conventions
• Filter by app or space: extend the App Reload Finished webhook event filter to only alert for specific production apps or managed spaces
• Connect to a ticketing system: automatically create incidents in ServiceNow or Jira for severe app reload failures

Tips for new users

• Test the automation on a non-production analytics app first.
• Keep the AI prompt concise and specific so responses stay focused.
• Make sure all connectors are authenticated before running the template.
• Check the automation run history if the Slack message is missing or incomplete.
• Review the AI response for accuracy. It is designed to start the investigation, not replace your own validation.

Troubleshooting

The automation does not send a Slack message:

• Confirm the reload event had Reload status eq "Failed (error)" and Usage eq "Analytics".
• Verify the Slack and OpenAI connections are authenticated and valid.
• Check that the user running the automation has access to the app and space.

The AI response is too long:

• The template falls back to a run history link, which is expected behavior and avoids message truncation.

A reload you expected to see was not processed:

• Check whether the app is a session app. It will be skipped.
• Verify the reload was an analytics app reload and not a data preparation reload. Data preparation reloads are excluded at the webhook level.
• Confirm the event filter on the webhook block is correct.

Summary

This template gives you a focused, low-noise starting point for AI-assisted analytics app reload failure handling in Qlik Cloud. By filtering to analytics app errors only and excluding both session apps and data preparation reloads, it keeps alerts relevant and actionable. Teams can respond faster to app load script issues by receiving a clear Slack notification with context and an AI diagnosis the moment something goes wrong. You can modify the automation by adjusting the AI prompt, changing the destination channel, or adding escalation steps such as email or Microsoft Teams alerts.