Studio Search Sample Use Case

Overview

Let's configure a saved search based on these parameters:

• Role: Support Engineer / QA / Launch Coordinator
• Goal: Detect lab failures correlated with a specific instructions set language — especially useful when rolling out a lab in a new language for the first time
• Cadence: Weekly
• Page: Find Lab Instances (/LabInstance)

The Challenge

Your organization has published a lab — or a new language version of an existing lab — and you need to confirm it is launching successfully at scale. You are not watching individual launches in real time. Instead, you need a repeatable, weekly check that answers:

"Did any labs fail last week, and is there a pattern tied to a specific language or instruction set?"

This matters because:

• A lab that works perfectly in English may have a misconfigured instruction set in Spanish, Japanese, or another language — and failures may only appear once real users start launching it.
• Without a targeted search, failed launches are buried across thousands of rows with no easy way to spot a language-specific spike.
• The earlier you catch this, the fewer users are impacted and the easier it is to isolate the root cause.

The Goal

By the end of this weekly check you should be able to answer:

1. Did any labs end in an error state in the last 7 days?
2. Is the failure rate concentrated on a specific language?
3. Is the failure tied to a specific instruction set ID?
4. Is this a new pattern (started this week) or an ongoing issue?

One-Time Setup: Building Your Saved Search

Do this once. After that, it is a two-click weekly check.

Step 1 — Open Find Lab Instances

Navigate to Find Lab Instances from the Admin portal. This is the only search page in Studio that includes both the Instructions Set Language and Instructions Set ID filters.

Step 2 — Add Filters

Add the following filters using the Add Filter button:

Step 3 — Configure Output Columns

Click Output Options and enable these columns. The ✓ ones are on by default; the ➕ ones need to be turned on:

Step 4 — Sort the Results

Click the Instructions Set Language column header to sort. This groups all failures by language, making patterns immediately visible.

Step 5 — Save the Search

1. Click Save Search
2. Choose Create new saved search
3. Name it: Detect Language Failures – Last 7 Days

Why this name?

• Detect — signals a proactive check, not a reactive lookup
• Language Failures — names the question you are answering
• Last 7 Days — the time scope is visible without opening the search

The Weekly Check (2 Minutes)

Every Monday morning (or your preferred day):

1. Load the Saved Search

Find Lab Instances → Open Saved Search → Detect Language Failures – Last 7 Days

Results load automatically. The End Time filter recalculates from today — no date changes needed.

2. Read the Result Count First

3. Scan for Language Clustering

With results sorted by Instructions Set Language, look for any language that has significantly more rows than others.

Example reading:

A language with a disproportionate count is your signal. It does not prove a bug yet — but it tells you where to look next.

4. Check the Total Run Time Column

For the suspect language rows, look at Total Run Time:

Short run times concentrated in one language on a recently-published lab are a strong indicator of a launch-time misconfiguration.

5. Check the Instructions Set ID Column

If the language spike is there, look at the Instructions Set ID column for those rows:

• All the same ID? The problem is almost certainly in that one instruction set configuration. This is your root cause target.
• Multiple different IDs? The problem is broader — it may be a platform-level issue for that language, not one specific set.

When You Find a Problem — Drill Down Workflow

1. In the current results, identify an affected instance. Note its Number.
2. Click the Lab Profile link → confirms the lab and its settings.
3. Navigate to Find Lab Instance Errors, filter by that instance's Lab Instance ID.
4. Review the Message, Source, and Type columns — this is the raw error log that tells you what actually went wrong.

What a Healthy Week Looks Like

After running this check for several weeks, you will build a baseline sense of normal. A healthy week typically looks like:

• Zero or very low error counts (1–3 isolated instances across all languages)
• No single language accounting for more than ~50% of errors
• Short run-time failures are rare or absent
• Errors are distributed across different lab profiles rather than concentrated on one

Any week that deviates from your baseline pattern — especially in a language that was recently launched — warrants a drill-down before the issue affects more users.

Adapting This Search for a Specific Language Launch

When you have just published a lab in a new language (e.g., Arabic), run a tighter version of this check during the first two weeks post-launch:

1. Load Detect Language Failures – Last 7 Days
2. Add an Instructions Set Language = Arabic filter on top
3. Remove the State = Error filter temporarily — replace it with no State filter so you can see all instances, both successful and failed, to understand the launch volume
4. Compare the failed count against the total count for that language to calculate a failure rate

Summary

Related Resources