When your AI agent's deployment fails, it can open the support ticket too

Q: How does the agent follow up on a support ticket?

nexusai_support_ticket_list to see open tickets, nexusai_support_ticket_get to read a thread, and nexusai_support_ticket_reply to respond. The agent can confirm a fix worked and ask for the ticket to be closed, all from chat.

When an agent deploys your app and the deployment fails, it can open the NEXUS AI support ticket too. The workflow, the escalation rules, and what to put in it.

By NEXUS AI Team • September 6, 2026 • AI Deployments

Published: September 6, 2026 Category: AI · MCP · Operations Reading time: 9 minutes Author: NEXUS AI Team

An agent wrote the code. An agent built the container. An agent ran the deploy. Then the health check went red and the agent stopped, because that is where most agent workflows end: generation succeeds, operations fail silently, and a human finds out later.

It does not have to end there. The same NEXUS AI MCP connection that let the agent deploy also lets it read the logs, try the reversible fixes, and, when the problem is on the platform side, open a support ticket with the full context already attached.

This post is the workflow for that last step. When to escalate, what to put in the ticket, and how to keep the agent from filing noise.

Why an agent-filed ticket is a better ticket

A human filing a deployment ticket at 2 AM writes three sentences and goes back to bed. "Deploy is failing. Not sure why. Here is the URL." The support engineer then spends the first reply asking for the deployment ID, the build logs, the last thing that changed, and the exact error text.

The agent already has all of that. It is in the conversation. It knows the deployment ID because it created the deployment. It has the build logs because it just read them. It knows what changed because it made the change. An agent-filed ticket can open with the evidence that a human ticket takes two round trips to collect.

That is the real argument for handing this to the agent. Not that humans cannot file tickets, but that the agent is holding the context at the exact moment it is worth capturing.

Before the agent files anything

Most failed deploys are not support tickets. They are one of:

A build error in the generated code. The agent should read the log, fix the code, and redeploy.
A missing environment variable or secret. The agent should check what the app expects and what is set.
A bad start command or port. The agent should correct it and redeploy in place.
A transient failure. A plain redeploy fixes it.

A support ticket is for the cases that survive all of that: the build succeeds but the container never becomes healthy, a platform resource is stuck, provisioning hangs, or the behavior contradicts the documentation. Teach the agent to exhaust the cheap fixes first. The workflow below builds that in as Step 3.

Connect the NEXUS AI MCP server

If the agent already deploys to NEXUS AI, this is done. If not:

claude mcp add --transport http nexus-ai https://mcp.nexusai.run/mcp

For Claude Desktop, ChatGPT, Cursor, or any other MCP client, add the same URL as a custom connector and sign in with your NEXUS AI account. Authentication is OAuth, so the agent acts as you, sees only your organization, and every call it makes is written to the audit log against its own token. Full setup for each client is in MCP-driven deploys.

The four support tools the agent needs:

Tool	Purpose
`nexusai_support_ticket_create`	Open a ticket. Requires `subject` and `description`. Optional `priority` and `category`.
`nexusai_support_ticket_list`	List your organization's tickets, filterable by status.
`nexusai_support_ticket_get`	Read one ticket and its full message thread.
`nexusai_support_ticket_reply`	Post a reply into an existing ticket.

The failure-to-ticket workflow

Step 1 - Confirm the deployment actually failed

A red status in one place is not confirmation. The agent should check status and health together before deciding anything is wrong.

nexusai_deploy_status   deploymentId: <id>
nexusai_deploy_health   deploymentId: <id>

status tells you whether the build finished and what state the deployment is in. health returns the health check result and recent health-probe output. A deployment that is RUNNING with a failing health check is a different problem from one stuck in BUILDING, and the ticket should say which.

Step 2 - Pull the evidence

nexusai_deploy_logs   deploymentId: <id>

This returns the recent build and runtime log lines. The agent should read them, not summarize them away. The specific error string is what a support engineer searches for. The agent should also note, from its own conversation history:

The deployment ID and the deployment URL.
The framework and provider (NEXUS AI managed, AWS, Google Cloud, or Azure).
The last change it made before the failure, and whether a previous revision of this deployment was healthy.

Step 3 - Try the reversible fixes

If a previous revision was healthy and the current one is not, roll back first and confirm the app recovers:

nexusai_deploy_rollback   deploymentId: <id>

If the failure looks transient, or the fix was a corrected env var or start command, rebuild in place:

nexusai_deploy_redeploy   deploymentId: <id>

Redeploy keeps the same deployment ID, the same URL, and the same attached databases. If either of these resolves it, there is no ticket to file. The agent should report what it did and stop.

Step 4 - Open the ticket with full context

If the deployment still will not become healthy and the cause is not in the code or the configuration, this is a platform issue. Open the ticket:

nexusai_support_ticket_create
  subject:     Deployment <id> builds successfully but never passes health check
  description: |
    Deployment ID: 84a423e5089f
    URL: https://my-app.nexusai.run
    Provider: NEXUS AI managed
    Framework: Next.js

    The build completes and the container starts, but the HTTP health
    check on port 3000 has failed continuously for 20 minutes. The app
    logs show it bound to port 3000 and printed "ready on 3000".

    Last runtime log lines:
    <paste the exact lines>

    Tried: redeploy in place (same result), rollback to the previous
    revision 7c1f0a2 (that revision is healthy). The only change between
    them is an added POST /api/upload route.
  category:    deployment
  priority:    HIGH

Category should be deployment for a deploy that will not run, database for a managed database problem, billing for anything about plan limits or charges, technical for API or MCP behavior, and general for the rest. Priority should be URGENT only for a production outage with users affected, HIGH for a blocked deploy with no workaround, MEDIUM for most things, and LOW for questions.

The tool returns the ticket ID. The agent should surface it to you.

Step 5 - Track and close it

The ticket is a normal ticket. It appears in the dashboard Support screen, and the agent can follow it from chat:

nexusai_support_ticket_list   status: OPEN
nexusai_support_ticket_get    ticketId: <id>

When the team replies with a fix or a question, the agent can respond in the same thread:

nexusai_support_ticket_reply
  ticketId: <id>
  message:  Applied the suggested start command override. The health
            check passed on the next redeploy and the container is
            stable. Please close this.

There is one queue. A reply the agent posts here is visible to you in the dashboard, and a reply you post in the browser is visible to the agent.

What a good agent-filed ticket looks like

The difference is entirely in the description.

Weak:

My deployment is not working. Can someone look at it?

Strong:

Deployment 84a423e5089f (https://my-app.nexusai.run, NEXUS AI managed, Next.js). Build succeeds, container starts, HTTP health check on port 3000 has failed for 20 minutes. App logs show it bound to 3000. Rollback to revision 7c1f0a2 is healthy; the only diff is a new POST /api/upload route. Redeploy in place did not help. Runtime logs attached below.

The strong version is answerable on the first reply. The agent can produce it in one turn because it is not reconstructing anything. It is reporting what it already did.

A system prompt for knowing when to escalate

Drop this into the agent's instructions for operations work:

When a NEXUS AI deployment fails:
1. Check nexusai_deploy_status and nexusai_deploy_health.
2. Read nexusai_deploy_logs in full. Identify the exact error.
3. If the error is in the code or config, fix it and redeploy.
4. If a previous revision was healthy, roll back and confirm recovery.
5. If the build succeeds but the container never becomes healthy, or a
   platform resource is stuck, or behavior contradicts the docs: open a
   support ticket with nexusai_support_ticket_create. Include the
   deployment ID, URL, provider, framework, exact error lines, and every
   fix you already tried. Category "deployment". Priority "HIGH" unless
   users are affected, then "URGENT" and tell me first.
6. Never open a second ticket for a problem that already has an open one.
   Check nexusai_support_ticket_list first.
7. Report the ticket ID to me.

What the agent should not do

File duplicates. Before creating a ticket, the agent should call nexusai_support_ticket_list with status: OPEN and check whether this deployment already has one. A second ticket for the same failure splits the thread.

File for user errors. A wrong environment variable, a typo in the start command, code that does not compile: the agent fixes those, it does not escalate them.

Open URGENT tickets unattended. URGENT should mean a human is also being paged. The agent should confirm with you before setting it, unless you have explicitly told it that a production outage is always URGENT.

Paste secrets into the description. nexusai_secrets_list returns names and metadata, never values, and the platform never returns a decrypted secret over the API or MCP. The agent should keep it that way and never quote a secret value, a token, or a connection string into a ticket body.

Frequently asked questions

Can Claude or ChatGPT actually create a support ticket on my NEXUS AI account?

Yes. Once the NEXUS AI MCP connector is attached and signed in, the assistant can call nexusai_support_ticket_create. It acts as your account, scoped to your organization, and the ticket is identical to one opened from the dashboard.

Does an agent-filed ticket go to a different queue?

No. There is one queue. Tickets opened through MCP appear in the dashboard Support screen with the same thread, and replies posted in either place are visible in both. See the customer support page for the full picture.

Which NEXUS AI plans include support tickets?

Starter and above. Starter includes email support and support tickets. Pro adds phone support on top. Free is community support. The pricing page has the breakdown.

Should the agent try to fix the deployment before filing a ticket?

Yes, and the workflow above makes that Step 3. Read the logs, fix code or config errors, roll back if a previous revision was healthy, and redeploy. A support ticket is for what survives all of that: a build that succeeds but never runs, a stuck platform resource, or behavior that contradicts the documentation.

How does the agent follow up on a support ticket?

nexusai_support_ticket_list to see open tickets, nexusai_support_ticket_get to read a thread, and nexusai_support_ticket_reply to respond. The agent can confirm a fix worked and ask for the ticket to be closed, all from chat.

What stops an agent from spamming tickets?

Instruction and the audit log. The system prompt above tells it to check for an existing open ticket first. Every ticket action is recorded against the agent's token, so a misbehaving agent is visible and its access is revocable from the dashboard.

Can the agent see other organizations' tickets?

No. The connector signs in as you, so it reaches only your own organization, with no more access than your account has.

Where to start

Give your agent read access first and watch it triage a few failures. When you trust its judgment on what is a real platform issue, let it file. From that point, a failed deploy at 2 AM is a ticket that is already written, already has the logs, and is waiting for a reply when you wake up.

Start free and connect the MCP server, or read Your AI app is generated. Now how do you deploy it? for the wider shift this is part of.