Skip to main content

How do I know if my instance is reaching capacity?

If the instance experiences processing overload, specific signs emerge, which are detailed in this article.

Louis Machado avatar
Written by Louis Machado
Updated over 3 months ago
⚠️ When you subscribe to a paid plan, Xano provides you with a dedicated instance on a single-tenant architecture deployed in the server region of your choice. 

This setup guarantees that your server remains isolated from any global instabilities and that your instance is always influenced exclusively by its own executions and internal processes.

1. Unknown errors or Exceptions in the debugger.

They are critical resource issues. Because it is not an issue in the logic (underlying code), it is not caught by the debugger.

Note that exception errors can also occur due to Preconditions functions.



2. Spikes in RAM usage or CPU usage.

Usage charts (CPU, Memory, Database Storage) work on an average per-minute basis. While high usage isn’t always a concern, abrupt sharp spikes, such as the ones below, indicate resource peaks that hit 100% and max out during workflow execution.

3. 502, 503, or ECONNREFUSED errors.

4. Restarting Resources

By selecting the ⚙️ icon beside the instance name and choosing Maintenance > Server Maintenance, you can observe if resources are restarting.

When the resources max out, they restart to reset the pod, clear the data, and prepare to handle new data. This cycle, which lasts a few seconds, will persist until the issue causing the server overload stops.


5. Reconnecting Pop-ups.

These occur for the same reason mentioned in point 4, but they are usually smaller crashes. If this happens frequently, it indicates heavy activity on your instance, causing resource restarts. You can confirm this by following the earlier steps.

6. Longer processing times than usual.

When the server becomes overwhelmed, it first slows response times (Learn More), then times out certain workflows (throwing exceptions or unknown errors), and ultimately starts denying new requests (resulting in 502 errors). More details for both errors are provided above.

7. Unidentified CORS errors.

Browsers send preflight requests, and if they are denied, it will lead to a CORS error. However, if your instance has reached its resource limits, what appears to be a CORS error could actually be related to performance issues, resulting in a 502 status code.


To understand the browser's actual response to the request, refer to the steps illustrated in the image below.

8. Laggy interface.

You may experience lag in the visual API editor if:​

  • Your function stack is long, with a large number of steps.

  • You have a large volume of backend objects (APIs, functions, tasks, triggers, etc.) in a single workspace, as all these elements are loaded into memory for convenient editing.

  • You keep many backend objects in draft mode with extensive reversible changes.

Consider breaking down tasks within the same workflow into custom functions, deleting unused backend objects, or publishing your changes for smoother performance.

Did this answer your question?