> For the complete documentation index, see [llms.txt](https://docs.luciq.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.luciq.ai/changelog/readme/2026-09.md).
# September 2026
Luciq product updates shipped in September 2026: force-restart cause analysis in MCP, Investigate any APM metric with AI, Inbox saved views, and more.
6 product updates shipped in September 2026. See [Product Updates](/changelog/readme.md) for the latest.
{% updates format="full" %}
{% update date="2026-09-28" tags="no-sdk-update-required" %}
## Triage and Forward Crashes from the Luciq MCP Server
#### Summary
Luciq MCP agents can now triage a crash and forward it to Jira, GitHub, Linear, or Slack. Investigate, assign, and file the ticket without leaving your IDE.
#### What's new?
* The new `update_crash` tool lets agents set a crash's status, priority, assignee, and team, add or remove tags, and add a comment to the activity feed, all in one call.
* The new `forward_crash` tool sends a crash to one of the app's integrations, such as Jira, GitHub, Linear, or Slack, and returns the link to the created issue. With Jira, it can also link the crash to an existing issue.
* Both tools work for crashes, app hangs, and non-fatal errors, and agents use them only when asked to change something.
#### Why this matters?
* Crash triage now runs end to end inside the IDE. Agents can investigate a crash, assign and prioritize it, and file the ticket without switching to the dashboard.
Documentation
{% endupdate %}
{% update date="2026-09-17" tags="no-sdk-update-required" %}
## MCP: understand why users are force quitting the app
#### Summary
The crash\_diagnostics MCP tool now explains force restarts, splitting them into frustration-driven, benign, and unexplained shares with the evidence behind each.
#### What's new?
* **`crash_diagnostics`** now adds a `force_restart_cause_analysis` section for force-restart crashes (`USER_TERMINATION`, `ANDROID_USER_TERMINATION`). It splits the sampled occurrences into `frustration_driven`, `benign`, and `unexplained` shares, each with its own occurrence count and confidence interval, plus the evidence, affected screens, and app versions behind them.
* The aggregation and the cause analysis generate independently, so `crash_diagnostics` returns whichever is ready and reports a separate `status` for each.
#### Why this matters?
* A force restart has no stack trace to read, since the app was still alive when the user killed it. Your agent can now explain the likely *why* behind the restart instead of only reporting how often it happens.
Documentation
{% endupdate %}
{% update date="2026-09-17" tags="no-sdk-update-required" %}
## Investigate any APM metric with Luciq Agent, Claude, or Cursor
#### Summary
An Investigate button on every APM metric opens Luciq Agent in the dashboard, or hands the metric to Claude or Cursor over MCP. It replaces the AI summary card.
#### What's new?
* Every APM metric page now has an **Investigate** dropdown in its header, offering **Luciq Agent**, **Claude Web**, **Claude CLI**, and **Cursor**. It covers **App Launch**, **Network**, **Screen Loading**, **Screen Rendering**, and **Flows**.
* **Luciq Agent** opens the agent panel in the dashboard with the metric already in context, and it pulls its Apdex, latency, failures, and daily trend through the Luciq MCP APM tools before writing up its analysis.
* **Claude Web**, **Claude CLI**, and **Cursor** open the tool with a prompt already filled in, the same way **Open in** works on bug reports. The prompt uses the Luciq MCP to fetch the metric's data and asks the agent to find what is degrading it.
* The **AI summary** card that used to sit on APM metric pages is gone. Its insights now come from the agent, on demand.
#### Why this matters?
* One AI experience across the dashboard. The insights you used to get from the summary card now come through Luciq Agent, where you can ask follow-up questions in the same thread instead of reading a fixed paragraph.
* Whether you investigate in the dashboard or in your editor, the same MCP tools feed the same data, so the answer does not change with the entry point.
#### Availability
* Live for all customers on the dashboard. **Luciq Agent** is in beta and enabled per account; the Claude and Cursor options are available to everyone. No SDK update required.
{% endupdate %}
{% update date="2026-09-16" tags="no-sdk-update-required" %}
## Saved views in the Inbox
#### Summary
The Inbox issues list now has saved views. Filter and sort it the way you work, save that under a name, and come back to it in one click.
#### What's new?
* A **view** holds a filter set and a sort order together, under a name you choose. Views appear as tabs above the Inbox filter bar.
* Create one from whatever you already have applied. Filter the issues list, sort it by any column, then save.
* **Edit a view in place**, adding or removing filters and changing the sort, without having to apply it first. Changes save back to the view rather than to whatever you happen to be looking at.
* Views are stored on your account rather than in your browser, so they are there on whichever machine you sign in from, and they are scoped per app.
* Switching between views is one click on its tab. **Clear** in the filter bar takes you back to the full ranked queue.
#### Why this matters?
* Teams rarely work the whole issues list. One person watches hangs and force restarts, another network failures, a third the bug reports, and until now each of them rebuilt that filter set on every visit.
* Because the sort travels with the filters, a view restores the exact ordering you work in rather than just the subset.
#### Availability
* Live for all customers on the dashboard. No SDK update required.
Documentation
{% endupdate %}
{% update date="2026-09-16" tags="no-sdk-update-required" %}
## Network monitoring: health at a glance, summary metrics, and release markers
#### Summary
Network requests now open with a day-by-day Health strip, a Summary row of key metrics, and release markers on every chart. Tie any drop to a release at a glance.
#### What's new?
* A **Health** strip at the top of every network request. Each day in the selected range is a cell colored by that day's Apdex rating, from Excellent to Unacceptable, so a bad day stands out in one row. **View occurrences** jumps to the requests behind it.
* A **Summary** row with the request's Apdex, P50 and P95 latency, throughput, unique users, client-side failures, and server-side failures for the selected period, each with its change against the previous period.
* **Release markers** on the Trends charts. Every app release in the range is drawn as a vertical line on the Apdex, throughput, and latency charts. Hover to see the release version and date.
#### Why this matters?
* The Health strip answers "is this request OK?" before you read a single chart, and shows exactly which days were not.
* Release markers put a version next to every dip, so a regression introduced by a release is visible without cross-checking deploy dates.
#### Availability
* Live for all customers on the dashboard. No SDK update required.
Documentation
{% endupdate %}
{% update date="2026-09-16" tags="no-sdk-update-required" %}
## Debug network failures from a request's Debugging tab
#### Summary
Every network request now has a Debugging tab listing its server-side and client-side failures, with a timeline of which ones are still active. See what is failing right now.
#### What's new?
* A new **Debugging** tab on every network request in APM. Filter it by date, app version, device, OS version, country, radio, carrier, feature flags, response time, payload size, and trace attributes.
* A **failures timeline** with one row per failure. Highlighted cells mark intervals with at least one failed occurrence, so you can see which failures are ongoing and which have already stopped.
* A **failures list** covering every server-side and client-side failure on the request, each labeled by type and showing its count and rate.
* Selecting a failure opens three views: **Outliers**, the segments where it occurs disproportionately often; **Poor occurrences**, its 10 slowest occurrences; and **Patterns**, a breakdown across each dimension.
#### Why this matters?
* Failures are grouped and labeled for you, so a client-side cancellation and a server-side 5xx no longer look like one undifferentiated error rate.
* Outliers and patterns point straight at the device, version, or country carrying the failure, which is where the fix usually starts.
Documentation
{% endupdate %}
{% endupdates %}
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.luciq.ai/changelog/readme/2026-09.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
