--- name: azion-show-your-own-page-when-no-origin-answers description: >- Replace the 502, 503, and 504 responses of a workload with your own page, served from a connector that reaches none of the failing origins. --- # Show your own page when no origin answers You replace the error a [workload](/en/documentation/platform/workloads/) returns when no origin answers with a page of your own, from Azion Console or the API. To replace other status codes, such as a `404`, refer to [Customize an error page](/en/documentation/guides/application-development/getting-started/customizing-error-response-page/). When no origin server can be selected, a request carries the upstream status `502`. When an HTTPS origin refuses the TLS handshake, the client receives `502` with the page titled `Azion - Default error page`. A custom page set binds a status code to a page that a [connector](/en/documentation/platform/connectors/) serves. A page for a code tagged Azion in the Console replaces the default Azion page. ```mermaid %%{init: {"layout": "dagre", "themeVariables": {"fontSize": "13px"}, "flowchart": {"nodeSpacing": 12, "rankSpacing": 12, "padding": 6, "wrappingWidth": 70, "minNodeWidth": 40, "useMaxWidth": true}}}%% flowchart TD Req["A request reaches the application's connector"] --> Answer{"Does an origin answer?"} Answer -->|"yes"| Origin["The client receives the origin's response"] Answer -->|"no: 502 or 504"| Set["The deployment's set has a page for the code"] Set --> Fetch["The page is fetched from its own connector"] Fetch --> Client["The client receives the page, with its custom status code"] ``` 1. A request reaches the connector that the application's *Set Connector* rule names. 2. When an origin answers, the client receives its response. 3. When no origin answers, the response carries a `502` or a `504`, and the custom page set of the workload's deployment holds a page for that code. 4. Azion fetches the page from the page's own connector, at the page's path. 5. The client receives the page in place, with no redirect, and with the page's custom status code. --- ## Prerequisites - A workload whose deployment names an application. To create one, refer to [Workloads quickstart](/en/documentation/platform/workloads/quickstart/). - A connector that serves your error page at a path and reaches none of your origins, such as a connector of type `storage` that reads an [Object Storage](/en/documentation/platform/object-storage/) bucket. For its fields, refer to [Connector settings](/en/documentation/platform/connectors/settings/#storage). - Access to Azion Console, for the Console procedure. Refer to [Access Azion Console](/en/documentation/guides/platform/account-and-billing/how-to-access-azion-console/). - A [personal token](/en/documentation/guides/platform/account-and-billing/personal-tokens/) for the API procedure, with the ID of the page's connector, of the workload, of its deployment, and of the application the deployment names. If the deployment names a firewall, its ID too. The examples serve the page at `/errors/503.html` on a connector named `error-pages`, for the domain `www.example.com`. Replace them with yours. --- ## Create a set with a page for each code The set binds `502`, `503`, and `504` to the same page. In the [Custom page settings](/en/documentation/platform/workloads/custom-pages/settings/#status-codes), `502` is a gateway that received an invalid response, `503` a server that is not ready, and `504` a gateway that received no response in time. Each page answers with `503`, which marks a temporary condition. The page comes from a connector that reaches none of your origins, because a page fetched from a failing origin fails with it. **Response TTL** sets how many seconds the page stays in cache, from 0 to 31,536,000. An error page is static and rarely changes, so a high value, such as `86400`, one day, keeps requests away from the page's connector. **Console** To create the set in Azion Console: 1. **Open the Custom Pages page** Access [Azion Console](https://console.azion.com/) > **Custom Pages**. 2. **Start the set** Select **Create Custom Page**. 3. **Name the set** In **Name**, enter a name that identifies the set, such as `origin-down`. 4. **Select Create Custom Page Code** 5. **Select the status code** In **Page Code**, select `502`. 6. **Keep the connector page type** In **Type**, keep *Page Connector*. 7. **Select the page's connector** In **Connector**, select `error-pages`. 8. **Enter the page path** In **Page Path (URI)**, enter `/errors/503.html`. 9. **Set the cache time and the status** Enter `86400` in **Response TTL** and `503` in **Response Custom Status Code**. 10. **Add the 503 and 504 codes** Select **Create Custom Page Code** again for **Page Code** `503` and `504`, with the same connector, path, **Response TTL**, and **Response Custom Status Code**. 11. **Select Create** The **Page Codes** table lists one row per page, with its **Page Status Code**, **Page Path (URI)**, **Custom Status Code**, and **Response TTL**. **API** To create the set with the API, send a `POST` request to the custom pages endpoint, with one entry in `pages` per status code. Replace `` with the ID of `error-pages`: ```bash curl --request POST \ --url https://api.azion.com/v4/workspace/custom_pages \ --header 'Accept: application/json' \ --header 'Authorization: Token ' \ --header 'Content-Type: application/json' \ --data '{"name": "origin-down", "active": true, "pages": [ {"code": "502", "page": {"type": "page_connector", "attributes": {"connector": , "ttl": 86400, "uri": "/errors/503.html", "custom_status_code": 503}}}, {"code": "503", "page": {"type": "page_connector", "attributes": {"connector": , "ttl": 86400, "uri": "/errors/503.html", "custom_status_code": 503}}}, {"code": "504", "page": {"type": "page_connector", "attributes": {"connector": , "ttl": 86400, "uri": "/errors/503.html", "custom_status_code": 503}}} ]}' ``` The API answers `201` with the new set, its `id` included. Record the `id` for the next task. The set holds one page for each of the three codes. It serves nothing until a workload's deployment names it. --- ## Assign the set in the workload's deployment The deployment of a workload names its application, its firewall, and its custom page set. Only the custom page set changes here, so the application and the firewall keep the values the workload uses today. The Azion CLI sets the custom page set only when it creates a deployment, and a workload holds one deployment, so this task uses Azion Console or the API. **Console** To assign the set in Azion Console: 1. **Open the Workloads page** Access [Azion Console](https://console.azion.com/) > **Workloads**. 2. **Open the workload** Select the workload that serves `www.example.com`. 3. **Select the set** In **Deployment Settings**, select `origin-down` in **Custom Page**. Keep **Application** and **Firewall** as they are. 4. **Select Save** Azion Console shows `Your workload has been updated`. **API** To assign the set with the API, send a `PATCH` request to the deployment of the workload, with the application the deployment names today and the ID of the set in `custom_page`. Leave out `firewall` if the deployment has no firewall: ```bash curl --request PATCH \ --url https://api.azion.com/v4/workspace/workloads//deployments/ \ --header 'Accept: application/json' \ --header 'Authorization: Token ' \ --header 'Content-Type: application/json' \ --data '{ "strategy": { "type": "default", "attributes": { "application": , "firewall": , "custom_page": } } }' ``` The API answers `202`. The deployment of the workload names the set. A deployment change takes several minutes to reach Azion's distributed infrastructure, and requests can receive Azion's default page until it does. --- ## Confirm the page replaces the error The check takes your origins out of service, so run it in a maintenance window. To confirm the page: 1. **Stop every origin of the application's connector** Stop the web server on each origin, or block the connections from Azion at its firewall. 2. **Request your domain** ```bash curl -s -D - https://www.example.com/ ``` 3. **Start the origins again** The response carries status `503`, from the page's **Response Custom Status Code**, and the body of `/errors/503.html`, not the page titled `Azion - Default error page`. It carries no `Location` header, so the client is not redirected. If the default page still arrives after the deployment change has spread, refer to [Troubleshoot Workloads](/en/documentation/platform/workloads/troubleshooting/#custom-pages). --- ## Next steps - [Custom page settings](/en/documentation/platform/workloads/custom-pages/settings.md): Every field of a set and its pages, and the 22 status codes a page can replace. - [Add a backup origin to a connector](/en/documentation/guides/application-performance/availability/add-a-backup-origin-to-a-connector.md): Keep a standby origin answering before the error page is needed. - [Customize an error page](/en/documentation/guides/application-development/getting-started/customizing-error-response-page.md): Replace the error responses of other status codes, each page with its own cache time. - [Keep an application online when an origin fails](/en/documentation/use-cases/improve-performance-and-reliability/keep-an-application-online-when-an-origin-fails.md): A primary and a standby origin in one pool, with this page when both fail.