> For the complete documentation index, see [llms.txt](https://docs.mozark.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.mozark.ai/no-code-studio/advanced/error-definitions.md).
# Error definitions
Every step can pass and the app can still end on an error screen: "Session expired", "Service unavailable", a payment declined.
An **error code** is a piece of text a run looks for on the screen at the end of each test case. If the text is there, the test case fails and the report says which code it was.
## 1. Open the error codes
Error codes live in the **project**, not in a test. Open them from a device session: **Test Creation** → start a session → **...** (left of refresh) → **Error codes**. The drawer lists every code in the project. Every run in the project checks all of them.
## 2. Add a code
Click **New error code**:
| Field | Example |
| ----------------- | ------------------------------ |
| Code | `E_TIMEOUT` |
| Matches on screen | `Request timed out` |
| Severity | `medium` |
| Description | Server took too long to answer |
**Code** and **Matches on screen** are required. Severity is free text: App Studio only shows it in the report, it does not change how the run behaves. A code must be unique in the project. Edit and delete from the row's menu, or select several rows to delete them together.
## 3. See it while you record
While you record, App Studio checks the screen in front of you against your codes. When one is on screen, an amber **⚠** appears in the inspector header, next to **...**. Click it: the panel lists the codes that matched (code, severity, the text that matched, and its description). **Re-check** runs the check again after the screen changes. *No errors* means nothing on this screen matches.
| Code | Severity | Match string | Matched on | Description |
| ----------- | -------- | ----------------- | ------------------------------------- | ------------------------------- |
| `E_SESSION` | high | `Session expired` | Session expired, please sign in again | Kicked back to the login screen |
## 4. Read it in the report
A test case whose last screen matched a code is marked **Failed**, with the code as its reason, even if every step passed. Open the session from the job report. Its drawer has an **Errors** tab. No Errors tab means no code matched. See [Reports](https://docs.mozark.ai/no-code-studio/running-and-reporting/reports).
## How matching works
* The screen is checked **once, at the end of each test case**, whether its steps passed or not. A code that flashes up mid-test and goes away is not caught.
* The match is **plain text, ignoring case**. `Session expired` matches `SESSION EXPIRED, please sign in again`. It is not a pattern: `*` and `.` are matched literally.
* It reads the **text on the screen** (the page source), not the pixels. Text drawn inside an image is not seen.
## Import and export
An existing suite's error definitions come in through **Import script**. Any CSV whose header has `error_code` and `match_string` is read as error codes (`description` and `severity` are picked up too):
```
error_code,match_string,description,severity
E_SESSION,Session expired,Kicked back to the login screen,high
E_DOWN,Service unavailable,,medium
```
Codes already in the project are reused when the code matches, ignoring case. When a run is packaged, every code in the project goes into it as `test_data/error_definitions.csv`: all of them, not only the ones a test uses. See I[mporting an existing script](/no-code-studio/authoring-tests/importing-an-existing-script.md).
## Worth knowing
| Symptom | Cause |
| ----------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| The error screen showed but no **Errors** tab | The text was not on screen when the test case ended, or it is inside an image. Or it differs: check spelling and spacing |
| A test case failed but every step passed | Its last screen matched an error code. The **Errors** tab says which |
| A code matches on every run | Its text is too common. `Session` matches any screen that says "session" anywhere. Use a longer phrase |
| Two codes fire on the same screen | Both texts are on it, or one contains the other |
| Code already exists | Codes are unique per project, ignoring case. Edit the existing one |
| The import counted an errors file as a data set | Its header is not `error_code`, `match_string`. Fix the header row |
| No step for error codes in the Step Builder | There isn't one. Codes are checked on every run; you do not add them to a test |
---
# 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.mozark.ai/no-code-studio/advanced/error-definitions.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.
