Is anyone else experiencing a recurring crash-loop affecting all background tasks?

Our pattern is very consistent:

- Tasks work normally for around 45 seconds.

- Then all tasks stop for approximately 5 minutes.

- The cycle repeats continuously.

- Our APIs remain online.

- Individual task executions are short, usually under one second.

- There is no long-running task before the crash.

- The dashboard does not show sustained high CPU or memory usage for tasks.

We already upgraded our task processing capacity after a previous recommendation from Xano.

We also significantly reduced the work performed by our tasks. Most of them now only trigger API endpoints and finish immediately. During a previous incident, we disabled and re-enabled tasks individually, but that did not identify any specific task or solve the problem.

The last time this happened, Xano investigated internally and identified Redis resource limits as the cause. They increased our Redis capacity, and the crash-loop stopped. Now the same behavior has returned.

Because detailed Redis metrics are not available in the dashboard, we cannot verify whether Redis is reaching a limit again.

Has anyone experienced the same pattern.. all tasks stopping together while APIs remain healthy and the visible task usage remains below capacity? If so, what was the root cause and how was it permanently resolved?

I used to smoke cigarettes and had successfuly rehabed using a rehab app so I thought it would be easy doing the same with my hair pulling, right?

Apperntly not.

I found out that hair pulling, like nail biting and skin picking are a part of a group defined by the DSM-5 as Body Focused Repetitive Behaviors (BFRBs)

This group of habits are defined by peoples difficulty to completly stop them “cold turkey” and many people just tend to live with them

One thing became very clear to me: for many people with BFRBs, simply deciding to “just stop” isn’t enough. And when an app is built entirely around the goal of never doing the behavior again, every slip can feel like failure.

So I decided to flip the equation with SoloUno.

Instead of focusing only on one huge, all-or-nothing goal, SoloUno focuses on small daily wins - becoming more aware of the habit, resisting urges when possible, reducing the behavior over time, and building confidence along the way.

And I wanted to make the process fun and engaging enough that people would actually want to keep practicing.

I started reading research, tried therapy myself, and learned about evidence-based approaches used for BFRBs, including Habit Reversal Training (HRT), CBT, and ACT. I wanted to take principles inspired by these approaches and turn them into something people could practice in their everyday lives.

And that became SoloUno ✨

Up-vote link - thank you!!

- The file and the files code come into the sandbox just fine after a push.

- Basically everything looks fine and as expected from inside the sandbox.

- When time to push to workspace from the sanbox, the diff correctly shows the lines of code being updated.

- Proceed to name the new workspace branch to push the updates into, and then perform the push.

- From inside the real workspace, when viewing the newly created branch, then navigating to the function, two of the four function references have been stripped from the function, breaking the function.

- No need to try to merge from there into an existing branch because the new branch is corrupted every time I push from the sandbox to workspace.

- For each push from the sandbox, this is to a new workspace branch every time, same results each time.

- I've already tried xano sandbox reset and xano sandbox delete, I get the same results each time.

The sandbox to workspace push can't be trusted.

- Work around so far.

- While inside the sandbox, I just copy the code from inside the function, then paste it directly into the desired workspace branch/function.

In the attached picture, the changes in green is what is being pushed out. The lines in red are what is received in the real workspace after the push.

Unfortunately, Xano Redis performance is a major production bottleneck.

As a real example, I have an endpoint that performs 74 Get Cache Value operations and it is now taking around 2 seconds (!!) to complete.

Even with platform overhead, I would not expect a Get Cache Value operation to take more than 1 ms on average. For 74 cache lookups, I would therefore expect the total Redis portion of the request to be well under 100 ms, not around 2,000 ms.

That translates to an average of roughly 27 ms per cache lookup, which is extraordinarily slow for an in-memory key/value store. In practice, I now frequently see individual cache reads taking longer than PostgreSQL queries, completely defeating the purpose of using Redis.

If an endpoint with just 74 cache lookups already spends around 2 seconds reading from Redis, what happens when hundreds or thousands of these api requests are executing in parallel?

Could the engineering team please investigate this as a priority?

When you build with an agent, you shouldn't have to re-explain your team's conventions every session. Xano Knowledge gives every agent that builds with Xano the same persistent, team-authored context: the in-product Xano Agent, and the local coding agents you reach through the CLI and Developer MCP. So whatever tool your team builds in, the agent builds the way your team builds.

Here's what's new:

• Three kinds of context, one library: A workspace AGENTS.md carries your always-on rules, Docs are on-demand reference the agent pulls in when a task calls for it, and Skills are step-by-step procedures for how your team does things—all authored as Markdown in your workspace.

• Author it three ways: Write Knowledge by hand in the Xano UI, through the Xano Agent, or via external coding agents over the Developer MCP—all writing to the same library, with reference files carried per skill.

• It reaches your local agents, too: The same context flows out to the coding agents you already work in through the CLI and Developer MCP, so your standards aren't trapped inside one tool.

• Inclusion modes keep sessions lean: Each skill decides when it enters the agent's context—always, on demand, or manual—so a large library never bloats a session. Invoke skills as persistent, removable pills when you want exact control, and preview precisely what the agent will receive before it runs.

• Reviewed and versioned like everything else: Every Knowledge change flows through the same push and commit review as any other agent edit, with a knowledge diff in the push modal and full version history—versioned just like your function stacks.

• Governed by admins: Admins lock and enforce both editing and inclusion, turning your team's standards into something agents apply repeatably—not optionally.

Before this, getting an agent to follow your standards meant re-explaining your conventions every session—and doing it separately in every tool you build with. Now that context persists, lives natively in the workspace, links to the files and function stacks it describes, and carries through to your local agents. Your team's standards stop depending on who's at the keyboard and start being something every agent applies, every time.

Head to Knowledge in your workspace and start authoring the rules, docs, and skills your team builds by. Let us know what you think.

New in 2.5: Pull, Push, and Deploy Your Static Frontend from the CLI and MCP

A lot of you build Xano from outside the workspace—through the CLI, the Developer MCP, and AI coding tools like Claude Code and Cursor. Your backend logic already lived in that loop. Your static frontend was in it too, but only partway: the CLI could upload, list, and inspect builds, but getting a frontend live still meant a manual detour—build it locally, zip it by hand, and upload it as a separate step. As of 2.5, we've brought the full static-hosting lifecycle into the same loop, so your whole app—frontend included—pulls, pushes, and deploys right from the tools you already work in.

Here's what's new:

• Push a build from a directory. Point the CLI at a folder and it zips and uploads for you—no manual packaging step. The build name is now optional (it auto-generates from the timestamp if you omit it), and for package.json builds the CLI waits for the build to finish and reports status, with a --no-wait option to return right after upload. You can still pass a zip directly.

• Pull a build back down. Download any build to disk—selectable by build ID, the latest, or by environment (dev/prod). Defaults to the original uploaded source, with an option to fetch the compiled output instead.

• Deploy across environments. Promote a specific build to dev or prod, so the same artifact moves cleanly through your environments.

• The agent knows how to ship it. Through the CLI and MCP, the agent is taught the full workflow—push your code, run the build, and deploy—so your frontend goes from local edits to live without hand-rolled deploy scripts.

• Same infrastructure as the rest of your app. Your static frontend deploys to dev and production on the same hosting and endpoints that already power the platform.

• A complete external development cycle. Build a full app—static hosting and all—without ever leaving your external toolchain, whether that's the CLI, the Developer MCP, Claude Code, or Cursor.

And there's more to the lifecycle in this release: create, inspect, and edit hosts directly from the CLI, delete builds you no longer need, and migrate v1 hosts to the newer instance-managed hosting tier.

Before this, building Xano from your own tools meant the external loop only partly reached your frontend—you could upload a build, but you still hand-zipped it and ran it as a separate step outside the flow, and automating anything beyond that meant standing up and maintaining your own deploy scripts. Now static hosting moves through the same pull, push, and deploy steps as the rest of your app, with the agent taught the workflow directly, on top of infrastructure Xano already runs.

Action Required in 2.5: SSE Transport for MCP Connections Is Now Deprecated

We're letting you know about an upcoming change to how MCP (Model Context Protocol) connections work in Xano.

As of 2.5, the SSE (Server-Sent Events) connection method is deprecated. This brings Xano in line with the official MCP SDK, which has already deprecated SSE in favor of a newer, more reliable transport.

What this means:

• SSE still works in 2.5. Nothing breaks in this release, but we recommend migrating at your earliest convenience.

• SSE will be removed in a future release. Connections still using SSE at that point will stop working, so switching now avoids any interruption later.

What you need to do: If you currently connect to your Xano built MCP servers using an SSE connection URL, update your configuration to use the Streaming connection URL instead. You'll find the Streaming URL in your MCP server's connection settings.

If you have any questions or need help migrating, reach out to Xano Support—we're happy to help.

However, I believe Xano has an opportunity to build something that goes far beyond what any external AI assistant can provide.

The first step, in my opinion, is that the Xano Agent itself should become capable of generating and maintaining frontend applications natively inside Xano. Rather than relying on external tools to create a UI, developers should be able to ask the Xano Agent to create a customer portal, administration dashboard, landing page or any other frontend, and have it generated directly into Xano Static Hosting.

The experience should feel completely integrated. The generated application should immediately appear in a live preview inside the Xano editor, allowing developers to interact with it while continuing the conversation with the Agent. Every AI-generated modification should be presented as a visual diff before being applied, allowing developers to review exactly what changed before accepting it. The project should maintain version history so previous revisions can be compared and restored, making experimentation safe and transparent.

Most importantly, developers should always retain full ownership of the generated project. The frontend should not become a black box. HTML, CSS and JavaScript should remain fully editable through Xano's editor, allowing developers to modify or extend the generated code whenever necessary. Since the application is being generated inside Xano, it could also automatically leverage xano-sdk-js for authentication, API communication and file handling instead of relying on manually written fetch requests.

I believe this alone would already provide an excellent developer experience. Developers could build, preview, edit, version and deploy complete frontend applications without ever leaving the Xano ecosystem.

However, I don't believe frontend generation is the most exciting opportunity.

The real opportunity begins once both the backend and frontend exist inside Xano.

Unlike external AI assistants, Xano is in a unique position to understand both sides of an application simultaneously. Instead of simply generating frontend code from an MCP session, the platform could continuously maintain knowledge of how every page, component and workflow depends on APIs, database fields, authentication rules, permissions and business logic.

That persistent understanding would enable capabilities that are impossible—or at least extremely difficult—for external AI assistants to provide.

For example, if a developer modifies an API endpoint, renames a database field, changes a response schema or updates authentication rules, the Xano Agent could immediately analyse the impact before the change is applied. It could identify every frontend page, component and workflow that depends on that change, explain the consequences and even generate the necessary frontend updates automatically.

The opposite workflow could be just as powerful. If a developer asks the Agent to add a new dashboard, create a new search filter, extend a form or build a completely new feature, the Agent could determine whether the current backend already supports those requirements. If additional endpoints, queries, indexes, database fields, business logic or permissions are required, it could propose or generate those backend changes before implementing the frontend.

This relationship should continue throughout the lifetime of the application.

If a field is renamed, every affected page could be updated automatically. If an endpoint is no longer referenced anywhere in the frontend, the Agent could suggest removing it. If similar backend logic starts appearing across multiple features, it could recommend consolidating duplicated functionality. If a new frontend requirement exposes architectural limitations in the backend, the Agent could proactively recommend improvements instead of waiting for developers to discover them manually.

Over time, Xano would become much more than a backend platform or an AI code generator. It would become the system that continuously understands the architecture of the entire application and helps developers evolve it safely.

This, in my opinion, is where Xano can truly differentiate itself.

External AI assistants already work very well with Xano through MCP, but they only understand the project during the current conversation. They do not own the project. They do not continuously track its evolution. They cannot maintain a persistent relationship between backend and frontend because those assets live outside their control.

Xano, on the other hand, has the opportunity to become the single source of truth for the entire application. By managing both the backend and the frontend, the Xano Agent could maintain a persistent dependency graph across APIs, database models, authentication, permissions and user interfaces, enabling intelligent impact analysis, automated synchronization, architectural guidance and AI-assisted refactoring throughout the lifetime of the project.

I believe this represents a much bigger opportunity than simply adding AI frontend generation. It would transform Xano from an outstanding Backend-as-a-Service into a truly AI-native full-stack development platform, where developers can build, evolve and maintain complete applications within a single ecosystem. Rather than competing directly with general-purpose AI coding assistants, Xano would offer something they cannot: continuous, platform-native intelligence that understands not only how an application is built, but also how it evolves over time.

Inspired by OpenAI's new ability to create and publish web applications directly from ChatGPT, I'd love to see Xano evolve towards a platform where developers can create, preview, edit and deploy web applications through the Xano Agent and Xano Static Hosting, while uniquely keeping the frontend and backend continuously in sync throughout the entire lifecycle of the application.

https://www.youtube.com/watch?v=8zH_O74hZBw

FA

Use case: I wrote some XanoScript that was already a column constraint.