> ## Documentation Index
> Fetch the complete documentation index at: https://docs.curator.interworks.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Error Pages 

> Configure custom error pages to provide helpful messaging when users encounter access issues or broken links.

When things go wrong, you want to be sure to send the right messages to your audience.  By default, Curator has error
pages that will let users know when they don't have access, they visit a broken link, or a system is down.
Communicating exactly what you'd like in these situations can be made even easier by sending your users to a custom-made
error page.

**NOTE**: You must [create a page](https://docs.curator.interworks.com/site_content_design/pages/pages_overview.md)
first before setting it to your error page

## Setting up "Not Found" or "Access Denied" Pages

1. Login to the backend of your Curator instance (e.g. `http://curatorexample.com/backend`).

2. Navigate to the **Settings** > **Curator** > **Portal Settings** section from the left-hand menu.

3. Click on the "General" tab and expand the "Error Pages" section.

4. Using the dropdown, select a page from the list of pages you have created on Curator. You can set two pages here:

   * Access Denied (403) - Displays when a user does not have access to a specific link on Curator.
   * Not Found (404) - Displays when a user visits a link that does not exist on Curator, or visits an old deleted/moved link.

5. After making your selection from these dropdowns, save the Settings page.

**NOTE**: The Access Denied page is a portal-wide setting. Curator does not support per-Dashboard or per-group overrides
for this page, so the same Access Denied page displays for every restricted link regardless of which Dashboard or user
group triggered it. As a best practice, create a single custom page with general access-request guidance (for example,
instructions for contacting an administrator to request access) rather than Dashboard-specific messaging. For more
context, see the [Pages Overview](https://docs.curator.interworks.com/site_content_design/pages/pages_overview.md) and
[Frontend User Permissions](https://docs.curator.interworks.com/users_groups/user_security/frontend_user_permissions.md) documentation.

## Setting up "Tableau Server Down" (503 error) Page

Occasionally your Tableau Server may go down for maintenance reasons, or even unplanned issues.  In this case it's
helpful to tell your users that things will be back shortly, and redirect them to useful resources.
Follow the steps below to ensure your custom page displays when your Tableau Server is unavailable.

1. Login to the backend of your Curator instance (e.g. `http://curatorexample.com/backend`).
2. Navigate to the **Settings** > **Tableau** > **Tableau Server Settings** section from the left-hand menu.
3. From the "General" tab expand the "Errors" section.
4. Using the "Tableau 503 Error Page" dropdown, select a page from the list of pages you have created on Curator.
5. After making your selection from this dropdown, save the Settings page.

## Troubleshooting

If you have configured a custom Access Denied (403) or Not Found (404) page but users are still seeing the default
Curator error page instead of being redirected to your custom page, work through the steps below.

### Verify Your Curator Version

A bug in earlier Curator releases could prevent custom error pages from being saved or applied correctly. Confirm that
your instance is running Curator version `2026.04-05` or later, where this issue was fixed. The version is shown in the
backend under **Settings** > **Curator** > **System Upgrade**, or to the right on the backend home page.

### Confirm the Page Is Still Selected

1. Navigate to **Settings** > **Curator** > **Portal Settings** and expand the "Error Pages" section under the "General"
   tab.
2. Verify that your custom page is still selected in the Access Denied (403) or Not Found (404) dropdown. If the
   dropdown is empty, the page may have been deleted or renamed -- re-select it and save.
3. Open the page itself under **Content** > **Pages** and confirm it still exists and is published.

### Rule Out Browser Caching

Browsers can cache error responses, which may make it appear that the custom page is not being served even after the
configuration is correct. Open a private/incognito browser window and revisit the URL that triggers the error to
confirm the custom page is displayed for a fresh session.

The same caching behavior can also make a working link appear broken for one individual user. See
[A Single User Sees a "Not Found" or "Access Denied" Error](#a-single-user-sees-a-not-found-or-access-denied-error).

## A Single User Sees a "Not Found" or "Access Denied" Error

If one user reports that a page, Dashboard, or file they have opened before suddenly shows the Not Found (404) or
Access Denied (403) error page -- while other users can open the same link without a problem -- the cause is usually
on that user's machine rather than in Curator. Have the affected user work through the following steps before
escalating.

1. Open the same link in a private/incognito browser window and log in to Curator there before retrying the link, since
   a private window does not carry the user's existing Curator session. If the link works there, the problem is local
   to the user's normal browsing session.
2. Clear the browser's cache and cookies, then close and reopen the browser. A browser can hold on to a cached error
   response or redirect for a URL that is working again, and clearing cookies also discards a stale Curator session.
3. Log back in to Curator and retry the link, since clearing cookies logs the user out.
4. If the link still fails, try a different browser or device to confirm whether the problem follows the user or the
   machine.

**NOTE**: This is the user's own browser cache, which is not the same thing as the **Clear Cache** button in the
Curator backend. The backend button clears Curator's server-side cache for everyone, and it has no effect on what an
individual browser has already stored.

If the error persists in a private window, in a second browser, or for more than one user, then the cause is on the
Curator side. Open **Settings** > **Logs** > **Request Log** (see
[Backend Logs](https://docs.curator.interworks.com/site_administration/logging/database_logs.md#request-log)). The Request Log lists each URL that led to
a Not Found (404) or Access Denied (403) page, with a count of how many times it happened. It records requests only
while **Log bad requests** is on, and that switch is off by default, so turn it on and ask the user to open the link
again.

The Request Log does not record which user made the request. The System Log (see
[Server Logs](https://docs.curator.interworks.com/site_administration/logging/file_based_logs.md#system-log)) has a warning with the user's name that looks
like this:

Page redirect: 404 content not found - logged in user: jane.doe.  Original url: /sales-overview

On a SaaS instance, contact InterWorks support for the System Log entry.

Neither log records the underlying reason the lookup failed. Use them to identify the affected link and user, then
confirm the requested resource still exists in the backend:

* For a page, confirm it exists and is published under **Content** > **Pages**.
* For a Dashboard, confirm it exists under **Tableau** > **Dashboards** or **Power BI** > **Dashboards**, depending on
  which platform the Dashboard belongs to.
* For a file, confirm it exists under **Content** > **Files**.

Then confirm that the user's group still grants access to that resource. See
[Frontend User Permissions](https://docs.curator.interworks.com/users_groups/user_security/frontend_user_permissions.md) for how access is evaluated.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.