Skip to main content
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 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 and Frontend User Permissions 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

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). 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) 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 for how access is evaluated.