## Opening the project webhook settings page
Before you start, make sure you have **Project Administrator** access for the project you want to review. In Atloria, webhook settings are managed at the project level, so you need permission to open the project’s **Settings** area and work with its delivery options.

1. Open the target project from your project list or workspace.
2. In the project sidebar, click **Settings**.
3. Inside **Settings**, open the **Webhooks** area.

[SCREENSHOT: Project sidebar with Settings selected and Webhooks highlighted]

On the **Webhooks** page, look for the main parts of the screen that help you monitor delivery behavior:

- A **webhook list** showing the webhooks configured for this project
- **Status indicators** that help you spot whether a webhook is active or having delivery problems
- A **recent delivery** or **delivery history** area for checking recent attempts
- **Action buttons** that let you open details, inspect a delivery, or retry a failed attempt

This page is focused on the current project only. Use it to confirm whether this specific project is sending events to the right destinations and whether those deliveries are succeeding. If your team also manages broader admin settings in Atloria, keep in mind that the **project Webhooks** page shows project-scoped webhook behavior rather than organization-wide admin tools.

If you need help getting to the right project workspace first, see [Managing Project Settings and Website Options](doc:managing-project-settings-and-website-options). That guide covers the general project settings area, while this page focuses on checking webhook behavior and delivery results after setup.

## Reviewing configured webhooks and their current behavior
Once you are on the **Webhooks** page, start by reading through each webhook entry in the list. The goal is to confirm that every webhook shown belongs in this project and is set up to react to the right project activity.

1. Scan the webhook list and open each entry one at a time.
2. Check the destination shown for that webhook.
3. Confirm whether the webhook is **enabled** or **disabled**.
4. Review the events or triggers attached to that webhook.
5. Open the webhook details to inspect its latest delivery information.

[SCREENSHOT: Webhook list showing destination, status, subscribed events, and last delivery result]

In the details view, pay attention to the delivery-related information Atloria shows for the webhook. This usually includes the most recent delivery result, the latest response code, and when the last attempt happened. These details help you quickly tell whether the webhook is healthy or whether it has stopped receiving useful traffic.

Compare what you see with the way your project actually works. For example, if your team expects notifications when documentation changes, version activity happens, or other project events occur, the webhook should be subscribed to those matching events. If the event list does not match the workflow your team depends on, the webhook may appear healthy while still missing the updates you expect.

You can often spot problems without opening every delivery record. Common warning signs include:

- A webhook that is **disabled** when it should be active
- Repeated failed results in the latest delivery information
- A **last delivery** time that is much older than expected
- A response code pattern that suggests the receiving service is rejecting requests

If the webhook setup itself needs broader review, refer back to [Configuring Project Webhooks and Related Controls](doc:configuring-project-webhooks-and-related-controls). Use this page to verify behavior, not to repeat the original setup process.

## Checking delivery controls and recent delivery activity
After confirming the webhook list looks correct, open an individual webhook and move to its delivery activity area. This is where you check whether Atloria is actually sending events and whether the receiving destination is responding successfully.

1. Click a webhook in the **Webhooks** list.
2. Open the section that shows **recent deliveries** or **delivery history**.
3. Review the most recent entries in order.
4. Open a specific delivery record to inspect its details.
5. Use any available retry or redelivery action if you need to test again after a fix.

[SCREENSHOT: Webhook detail view with recent deliveries list and a selected delivery record]

The recent deliveries area helps you answer a simple question: did a project action produce a webhook attempt? If your team recently changed documentation, updated project content, or performed another subscribed action, you should see a matching delivery entry appear soon after.

Open individual delivery records to inspect the details Atloria shows for each attempt. Focus on the fields that are easiest to compare across attempts:

| Field | What to check |
|---|---|
| Status | Whether the delivery succeeded or failed |
| Response code | Whether the destination accepted the request |
| Delivery time | When Atloria sent the event |
| Error message | Any message returned when the attempt failed |

If Atloria offers a **Retry**, **Redeliver**, or similar action, use it after the receiving destination has been corrected. This is especially useful when the original failure was caused by a temporary issue. A successful retry tells you the webhook setup is likely correct and that the problem was with the destination’s availability or response at the time of the first attempt.

When several recent entries show the same failure pattern, treat that as a sign of an ongoing issue rather than a one-time interruption.

## Confirming that webhook deliveries are working as expected
The best way to confirm a webhook is working is to trigger a project action you can recognize easily, then check whether a new delivery appears in the webhook’s history.

1. Perform a known action in the project that should trigger the webhook.
2. Return to **Settings** > **Webhooks**.
3. Open the relevant webhook.
4. Refresh or review the **recent deliveries** list.
5. Match the new delivery entry to the action you just performed.

[SCREENSHOT: Recent deliveries list with a newly added event highlighted]

When you inspect the new entry, compare the **timestamp** and **event type** with the action you just completed. The timing should line up closely enough that you can confidently say the new record came from your test. This is the quickest way to verify that Atloria is not only configured to send events, but is also sending the right event at the right time.

Look for success indicators in the delivery record. In most cases, a successful delivery will show a delivered or successful status and a response code in the **2xx** range. If you see that result after your test action, the webhook is behaving as expected for that event.

Do not rely on a single successful attempt if you are investigating a recurring problem. Repeat the check with more than one event so you can tell the difference between:

- a one-off failure,
- a temporary destination outage, or
- a persistent configuration problem.

If one event succeeds but another expected event never appears, the issue may be with the webhook’s event selection rather than the destination itself. If every test event fails in the same way, focus on the destination response shown in the delivery details.

This verification step works especially well after changes made in earlier project setup work, including the delivery options covered in [Configuring Project Identity and Delivery Options](doc:configuring-project-identity-and-delivery-options).

## Using delivery details to diagnose operational problems
When a webhook is not behaving correctly, the delivery details view gives you the clearest picture of what is going wrong. Instead of guessing, use the fields shown in Atloria to narrow the issue down.

1. Open the affected webhook from **Settings** > **Webhooks**.
2. Select a failed or suspicious delivery entry.
3. Read the status, response code, attempt time, and any response message.
4. Compare that delivery with earlier and later attempts.
5. Note the exact pattern before you escalate the issue.

[SCREENSHOT: Failed delivery detail showing status, response code, attempt time, and response message]

These fields help you separate different kinds of problems:

- **Status** tells you whether Atloria considers the delivery successful or failed.
- **Response code** helps you see whether the destination accepted the request or rejected it.
- **Attempt time** helps you match the failure to a real project action.
- **Endpoint response message** can reveal whether the destination returned a useful explanation.

Use the webhook’s overall state together with the delivery history. For example:

- If the webhook is **disabled**, missing deliveries may be expected.
- If the webhook is enabled but there are **no recent deliveries**, the triggering event may not have happened or the webhook may not be subscribed to that event.
- If deliveries appear but each one includes an error response, the destination is likely receiving the request and rejecting it.

The sequence of attempts matters. A single failed record surrounded by successful ones usually points to a temporary interruption. A repeating pattern across every recent event suggests a persistent problem. Intermittent success and failure often means the destination is unstable or only failing under certain conditions.

Before you hand the issue to the team that manages the receiving destination, record the exact webhook entry, the failing event, the delivery time, and the response details shown on screen. That gives them something specific to investigate.

## Fixing common webhook and delivery check issues
Most webhook problems in Atloria fall into a small number of patterns. Use the **Webhooks** page to confirm which pattern you are seeing before making changes or asking another team to investigate.

1. Open the affected webhook in **Settings** > **Webhooks**.
2. Review its enabled state, subscribed events, and recent deliveries.
3. Compare the latest delivery details with the project action you expected to trigger it.
4. Retry delivery only after you have corrected the likely cause.
5. Recheck the delivery history to confirm whether the issue is resolved.

Here are the most common situations and what to verify:

- **No recent deliveries appear**
  - Confirm the webhook is **enabled**.
  - Make sure a subscribed project event actually happened.
  - Check whether you are looking at the correct webhook for that event.

- **Deliveries keep failing**
  - Open the latest failed delivery.
  - Review the response code and any error message.
  - Correct the destination issue, then use **Retry** or **Redeliver** if Atloria shows that option.

- **An expected event is missing from history**
  - Compare the webhook’s event subscriptions with the action you performed.
  - If the action does not match the selected events, Atloria will not create a delivery for it.

- **Delivery checks are unclear**
  - Run more than one test event.
  - Compare timestamps across the recent deliveries list.
  - Look for a pattern: always failing, sometimes failing, or not appearing at all.

[SCREENSHOT: Webhook detail page with failed delivery selected and retry action visible]

If the webhook configuration itself seems incomplete, revisit [Configuring Project Webhooks and Related Controls](doc:configuring-project-webhooks-and-related-controls). If the project settings page shows the webhook is configured correctly but the destination keeps rejecting deliveries, share the exact delivery details with the team responsible for that receiving endpoint.

## Overview
This page in Atloria is where you verify that project webhooks are not only configured, but also actively delivering project events to the correct destination. The **Webhooks** area inside project **Settings** helps you review each configured webhook, inspect recent delivery attempts, and determine whether delivery failures are isolated or ongoing.

Use this page when you need to answer questions like:

- Is the webhook enabled for this project?
- Is it listening for the right project events?
- Did a recent project action create a delivery attempt?
- Did the destination accept or reject that delivery?
- Can the failed delivery be retried after the destination issue is fixed?

The most useful parts of the screen are the webhook list, the detail view for each webhook, and the recent delivery history. Together, these let you compare expected project activity with actual delivery records. If your team recently updated webhook setup, changed project delivery behavior, or connected a new receiving destination, this page is the fastest place to confirm the result.

This guide focuses on monitoring and troubleshooting from the project’s **Webhooks** settings page. It does not repeat the broader setup steps already covered in [Configuring Project Identity and Delivery Options](doc:configuring-project-identity-and-delivery-options) and [Configuring Project Webhooks and Related Controls](doc:configuring-project-webhooks-and-related-controls). Instead, it shows how to read the delivery information Atloria presents and how to use that information to verify successful behavior or diagnose failures.

If you are responsible for release readiness or operational checks, reviewing webhook delivery history here can help you catch missing notifications, repeated delivery failures, or event subscription mismatches before they affect downstream workflows.

## Prerequisites
Before working through delivery checks in Atloria, make sure the following are true:

- You can open the target project and access its **Settings** area.
- You have **Project Administrator** access for that project.
- At least one webhook has already been configured on the project’s **Webhooks** page.
- You know which project action should trigger the webhook you want to test.
- You can identify the correct webhook entry by its destination and subscribed events.

It also helps to have a recent project action available for testing. For example, if you are checking whether a webhook reacts to a specific project event, you should be ready to perform that action and then return to the **recent deliveries** list to confirm a new entry appears.

Before starting, gather these details from the webhook entry you plan to review:

| Item to confirm | Why it matters |
|---|---|
| Enabled or disabled state | Disabled webhooks will not send deliveries |
| Subscribed events | The webhook only sends deliveries for selected project activity |
| Last delivery result | Helps you see whether the webhook has been working recently |
| Latest timestamp | Shows whether delivery activity is current or stale |

If you have not yet reviewed the project settings area itself, start with [Managing Project Settings and Website Options](doc:managing-project-settings-and-website-options). If you need to revisit how project webhook options were originally configured, use [Configuring Project Webhooks and Related Controls](doc:configuring-project-webhooks-and-related-controls).

After you have confirmed webhook delivery behavior, the next step in the Project Settings sequence is [Planning Project Structure and Content Governance](doc:planning-project-structure-and-content-governance).