An audit target is everything that makes up one site or application: its servers, code repository, domains and live site, plus the language and framework it's built with. A full health report audits all of it in one run and groups the findings by the part of the site they affect. You'll find targets under **Diagnose → Targets**.

If you only want to audit source code, start with [Repository audits](/assure-and-diagnose/repository-audits). Every repository you add gets a target automatically, so you can build on it later.

## Before you start

- Audits must be included in your package. See [Package and add-ons](/account-and-access/package-and-add-ons).
- You need permission to view targets and audits, and separate permission to create or change targets. See [Users, teams, groups and permissions](/account-and-access/users-teams-groups-and-permissions).
- Parts are picked from records that already exist in Structurell: servers on **Assure → Health**, repositories on **Diagnose → Repositories**, domains on **Account → Domains** and sites on **Assure → Monitoring**. You can also type a hostname for a server, domain or site.

## The Diagnose overview

Select **Diagnose** in the navigation for an overview. Depending on your permissions, it shows your open findings by severity and by layer, your average audit score, the latest scores for each target, recent health reports and audits, how your score has changed, any critical findings, and repositories that still need setting up.

## Creating a target

1. Go to **Diagnose → Targets** and select **New**.
2. Under **Target**, check the **Status** is **Enabled**, enter a **Name** and, optionally, a **Description**.
3. Optionally, fill in **Check settings**:
   - **Stale admin after (days)**: a store administrator who hasn't signed in for this many days is reported as stale. Leave it empty for 90.
   - **Allowed script domains**: hosts your store may load scripts from besides its own domains, one per line.
   - **Site paths**: application folders on a server part, one per line, such as `/var/www/shop`, for sites Structurell doesn't already know about.
4. Select **Save**. The **Parts**, **Schedules** and **UX review** sections appear.

## Adding parts

1. Open the target and go to **Parts**.
2. Choose a **Layer**: **Server**, **Language**, **Framework**, **Repository**, **Domain** or **Site**.
3. For **Language** or **Framework**, choose the **Platform**, such as **PHP**, **Laravel**, **WordPress** or **Adobe Commerce**. For the other layers, choose a **Record type** and then the **Record**. For example, a **Server** is one of your connected servers or a **Hostname**, and a **Site** is a **Monitored site** or a **Hostname**.
4. Optionally, enter a **Label**.
5. Select **Add part**.

To change a part, select **Edit**, make your change and select **Save**. To remove one, select **Remove** and confirm.

Once a repository is a part, select **Detect language and framework** to fill in the **Language** and **Framework** layers from its code. If you change a detected part yourself, detection leaves it alone from then on.

## Running a full health report

1. Open the target.
2. Select **Run full health report**.

Structurell runs every check that applies to the target's parts and opens the **Health report**. While the run is in progress, the page updates itself. The report shows:

- **Score** out of 100, and the run's **Status** and progress.
- Counts of **Critical**, **High**, **Medium**, **Low** and **Info** findings. **Info** means a check couldn't be assessed, for example because it timed out, so it isn't scored.
- A section for each layer, listing the parts in it and the findings that affect it. Select a finding to open it.

Use **Target** to go back to the target, **Run progress** to open the audit's full page with its steps, log and technology details, **Refresh** to reload, or **Run full health report** to start another run. The audit page works the same way as for a repository. See [Repository audits](/assure-and-diagnose/repository-audits).

## Scheduling audits

The target's **Schedules** section lists its schedules. Select **Add schedule** to run the health report, or part of it, automatically and choose who is alerted. See [Assurance reviews and audit schedules](/assure-and-diagnose/assurance-reviews-and-schedules).

## UX reviews

A UX review is a design review of the target's pages on desktop and mobile. It runs on demand, is billed per review and is never scheduled. The target needs a **Domain** or **Site** part.

The **UX review** section shows whether reviews are part of your subscription and how many are left this month. Select **Run UX review** to start one; its health report opens. If reviews aren't included or none are left, select **Add reviews** to change your package. See [Package and add-ons](/account-and-access/package-and-add-ons).

## The audits list

**Diagnose → Audits** lists every audit from your targets and repositories, newest first, with tiles for **Runs**, **Failed**, **Avg score** and **Last run**. An audit's status is **Pending**, **In Progress**, **Completed**, **Failed**, **Skipped** or **Blocked**. Select **View** to open one.

## Working with findings

Findings from every audit are gathered under **Diagnose → Findings**, where you can filter them, update their status and track them from one run to the next. See [Managing findings](/assure-and-diagnose/managing-findings).

## Troubleshooting

- **Run full health report shows an error.** The message explains why the run couldn't start. A common cause is that no checks apply to the target's parts, for example a target with no parts yet.
- **"Link a repository first to detect its language and framework."** Add a **Repository** part before selecting **Detect language and framework**, or add the **Language** and **Framework** parts yourself.
- **"You can't run a UX review for this subscription."** UX reviews aren't in your package. Ask an administrator to add them.