Resolving Cloudflare Workers 404 Error After Successful Deployment

Troubleshooting Staging Environment Issues with Cloudflare Workers

An essential stage in the development process is setting up a staging environment so that updates can be properly tested before going live. In this instance, Cloudflare Workers were keeping the primary website under development operating well.

After cloning the existing Git repository and connecting it to the staging environment through Cloudflare Workers & Pages, everything seemed to work fine. The logs indicated that the deployment was successful, which would typically signal the creation of a live instance.

export default {
  async fetch(request, env) {
    // Define your R2 subdirectory here. 
    // IMPORTANT: Make sure it ends with a trailing slash (/).
    const SUBDIRECTORY = 'my-website-folder/';

    try {
      const url = new URL(request.url);
      
      // Get the path from the URL (e.g., 'about.html')
      let key = url.pathname.substring(1);

      // If request is for a directory, append index.html
      if (key === '' || key.endsWith('/')) {
        key += 'index.html';
      }

      // Prepend the subdirectory to the requested key
      const objectPath = SUBDIRECTORY + key;
      const object = await env.R2_BUCKET.get(objectPath);

      // --- HANDLE 404 NOT FOUND ---
      if (object === null) {
        // Fetch custom 404.html from inside the subdirectory
        const notFoundObject = await env.R2_BUCKET.get(SUBDIRECTORY + '404.html');

        if (notFoundObject === null) {
          // Ultimate fallback if 404.html is missing
          return new Response('404 Not Found', { status: 404 });
        }

        const errorHeaders = new Headers();
        notFoundObject.writeHttpMetadata(errorHeaders);
        errorHeaders.set('etag', notFoundObject.httpEtag);
        // Ensure the browser renders it as HTML
        if (!errorHeaders.has('content-type')) {
          errorHeaders.set('content-type', 'text/html;charset=UTF-8');
        }

        return new Response(notFoundObject.body, { 
          status: 404, 
          headers: errorHeaders 
        });
      }

      // --- HANDLE SUCCESS (200 OK) ---
      const headers = new Headers();
      object.writeHttpMetadata(headers);
      headers.set('etag', object.httpEtag);
      return new Response(object.body, { headers });

    } catch (error) {
      // --- HANDLE OTHER ERRORS (500 Internal Server Error) ---
      console.error("Worker Error:", error);

      try {
        // Fetch custom 500.html from inside the subdirectory
        const serverErrorObject = await env.R2_BUCKET.get(SUBDIRECTORY + '500.html');
        
        if (serverErrorObject !== null) {
          const serverErrorHeaders = new Headers();
          serverErrorObject.writeHttpMetadata(serverErrorHeaders);
          if (!serverErrorHeaders.has('content-type')) {
            serverErrorHeaders.set('content-type', 'text/html;charset=UTF-8');
          }

          return new Response(serverErrorObject.body, { 
            status: 500, 
            headers: serverErrorHeaders 
          });
        }
      } catch (e) {
        // Silently fail and drop to the ultimate fallback below
      }

      // Ultimate fallback
      return new Response('500 Internal Server Error', { status: 500 });
    }
  }
};

But when the developer tried to access the given Cloudflare address, a 404 error message appeared, leaving him unsure of what went wrong. It can be annoying to deal with issues of this nature, particularly when there is a belief that the server should be live right away upon deployment.

It is unclear if a second server is needed or if there is something else that needs to be done in order to completely activate the new repository. We will look at the causes of this 404 problem and how to set up the Cloudflare Workers server correctly for the staging environment in this article.