Support Tickets

Get help from the Deploynix team through a built-in ticket system, with priority automatically matched to your plan.

Overview

Support tickets let you talk directly to the Deploynix team without leaving the dashboard. Every ticket belongs to an organization, captures a threaded conversation, and gets an automatic priority based on your subscription tier. When a staff member replies or changes the status of your ticket, you get an email. When you reply back, the whole team sees it on the admin side immediately.

Priority

There is one support tier. Every ticket opened by a Professional organization starts at High priority; there is no per-ticket picker and no add-on. Our team can raise a ticket to Urgent for an outage or a security problem, or lower it to Normal for a feature request, and the badge on your ticket changes accordingly.

Accessing Support

1. Click Support in the dashboard sidebar.
2. You land on a paginated list of every ticket your organization has opened, newest first.
3. Click Create Ticket to submit a new one, or click any row to open its thread.

The Ticket List

The Support index shows your organization's tickets with, for each row:

• The ticket subject — clickable, opens the thread.
• A status badge: Open, In Progress, Resolved, or Closed.
• A priority badge: Normal, High, or Urgent.
• The category label.
• A relative created at timestamp.

Tickets paginate in batches of 15. Scroll (or paginate) to find older ones.

Creating a Ticket

The New Ticket form asks for three fields:

• Subject — a short, searchable summary (up to 255 characters).
• Category — one of the five categories below; shapes how we route your ticket internally.
• Description — the full context (up to 5,000 characters). More detail is better — see Writing Good Tickets.

Categories

• General — anything that doesn't fit another bucket.
• Billing — subscriptions, invoices, payment methods.
• Technical — deployments, site configuration, environment variables, queue workers.
• Server Issue — provisioning failures, unreachable servers, broken SSH, network rules.
• Feature Request — things you'd like us to build.

When you submit a ticket, the Deploynix team receives an email notification immediately. Every ticket starts at High priority; you don't pick it yourself. You can attach up to five files (screenshots, PDFs, logs, JSON or zip, 5 MB each) to the ticket and to every reply; staff can attach files to their replies too.

Priority Levels

The Ticket Thread

Open any ticket from the list to see the full conversation. The thread shows the original description followed by every reply in order, with each reply marked as either you or staff. Staff replies have a distinct badge so you can skim for who said what.

The first staff reply automatically moves the ticket from Open to In Progress. You can reply back at any point while the ticket is not closed via the textarea at the bottom of the thread — up to 5,000 characters per reply. Every reply you post emails our team with its text and a link to the ticket, and a reply on a Resolved ticket puts it back to In Progress so it re-enters the queue.

Statuses

• Open — newly created, awaiting staff review.
• In Progress — a staff member has picked it up and is working on it. Set automatically on the first staff reply.
• Resolved — the staff member believes the issue is fixed. You can still reply; doing so reopens the ticket as In Progress.
• Closed — the ticket is finalized and no longer accepts replies.

Only staff can change a ticket's status. If you need to reopen a closed ticket, create a new one and reference the previous ticket's subject in the description — we'll link them internally.

Email Notifications

Deploynix sends four kinds of emails for tickets, all queued for fast dispatch:

• New ticket — sent to the Deploynix team when you open a ticket.
• Your reply — sent to the team when you reply, with the reply content and a link to the ticket.
• Reply — sent to the ticket creator when a staff member replies, with the reply content and a deep link back to the thread.
• Status changed — sent to the ticket creator when a staff member changes the ticket's status, with the old and new values.

API

Tickets are also available through the REST API with the support-ticket:read, support-ticket:create and support-ticket:update token abilities: GET /api/v1/support-tickets, GET /api/v1/support-tickets/{id}, POST /api/v1/support-tickets (subject, category, description, optional multipart attachments[]) and POST /api/v1/support-tickets/{id}/replies (message, optional attachments[]). Calls are scoped to the token owner's current organization; a plan without support tickets gets 403 with an upgrade_url.

Writing Good Tickets

A well-written ticket gets resolved faster because we don't have to go back and forth asking for context. A few things that help:

• Describe what you expected and what actually happened. "Deploy failed" is less useful than "Deploy failed at the npm run build step with exit code 1".
• Name the server and site. If the issue is scoped to one, the server name and site domain are the fastest way for us to find the logs.
• Include any error messages verbatim. Even if they look unhelpful, they let us search our own telemetry.
• Tell us what changed recently. A new deploy, a changed env var, a new cron job, a swapped DNS provider — anything that moved before the issue started.
• Say what you've already tried. Restarted Nginx? Reprovisioned? Rolled back? That narrows the suspect list fast.
• Use the right category. Billing questions in the Technical queue take longer because they get re-routed internally.
• Attach the evidence. A screenshot of the error and the relevant log file (up to five files, 5 MB each) save a round trip; short excerpts can also go straight into the text.