Support

Every ɳSelf Cloud plan includes support. What differs across plans is response time, coverage hours, and whether your plan includes P0 emergency response for full-stack outages. This page describes how to file a ticket, what each tier covers, and what falls outside our scope.

Response times by plan

"First response" means an engineer has acknowledged your ticket and is actively triaging it — not an auto-reply. Resolution time varies by severity and complexity; SLAs above are for first human acknowledgment only.

How to file a ticket

Dashboard (recommended)

Navigate to Dashboard → Support → New ticket. The form collects:

• Server instance name (auto-populated)
• Severity (P0 / P1 / P2 / P3)
• Description of the issue and steps to reproduce
• Attach logs (optional — see CLI log export below)

The ticket is created in our tracked queue and an alert fires to the on-call engineer for your tier immediately. You receive an email confirmation with your ticket ID.

Email

Send an email to support@nself.org from the address on file for your account. The body is auto-ingested as a ticket. Include your server instance name and severity in the subject line for faster routing:

Subject: [P1] myapp.cloud.nself.org — Hasura metadata reload failing

CLI

The CLI can open a ticket and attach recent logs in one command:

# Open a ticket with the last 500 lines of logs attached
nself cloud support myapp

# Output:
# Collecting logs from myapp.cloud.nself.org...
# Opening support ticket...
# Ticket #4821 created. First response SLA: 8 hours.
# Logs attached (487 lines, 12 KB).
# Track at: https://cloud.nself.org/support/4821

# Specify severity and message inline
nself cloud support myapp --severity p1 --message "Postgres OOM killed at 03:14 UTC"

# Export logs only (no ticket)
nself cloud logs myapp --tail 1000 --since 2h > myapp-logs.txt

What counts as a P0 emergency

P0 is reserved for conditions where your production stack is entirely unavailable or actively leaking data. Declare P0 only for:

• Complete stack outage — no requests being served at all
• Data loss or confirmed data exposure to unauthorized parties
• Active security incident (ongoing breach, credential compromise)
• Hasura or Auth completely down with no fallback

Everything else — including severe performance degradation, a broken plugin, or a failing scheduled job — is P1 or below. P1 through P3 follow standard first-response SLAs.

P0 escalation path

1. File a ticket in the dashboard or via email, mark severity P0.
2. For Business and MAX plans: call the emergency phone number from your welcome email. Have your instance name and ticket ID ready.
3. The on-call engineer will join a shared incident channel (Slack or Discord — your preference set in account settings) within the SLA window.
4. We post status updates to your incident ticket every 15 minutes until resolved.
5. A root cause analysis is emailed to you within 48 hours of resolution.

# Check current platform status
nself cloud status --platform

# Output:
# ɳSelf Cloud: Operational
# Falkenstein (fsn1): Operational
# Helsinki (hel1): Degraded (storage latency elevated — investigating)
# Ashburn (ash1): Operational
# Singapore (sin1): Operational
# Status page: https://status.nself.org

Severity definitions

What we support

• The ɳSelf CLI and all commands documented at Cloud CLI reference
• The backend stack: Postgres, Hasura, Auth, Nginx, MinIO, Redis
• All paid plugin bundles included with your Cloud plan (ɳSelf+)
• Provisioning, updates, backups, and SSL renewal
• Billing questions within 30 days of invoice date
• Migration help — moving from self-hosted to Cloud or between Cloud regions

What we do not support

• Application code you wrote. We support the stack, not your application logic. If your GraphQL mutation returns an unexpected result, that is your code.
• Third-party plugins not distributed by ɳSelf. Raise those with the plugin author. We can help verify whether the issue is in the plugin runtime or the plugin itself.
• Billing disputes older than 30 days. Stripe disputes are the mechanism after that window.
• General Postgres DBA work. We ensure the cluster is up; query optimization, schema design, and index tuning are your responsibility.
• Custom Nginx configuration. We manage nginx/sites/(generated). Files in nginx/conf.d/ are yours to manage and are preserved across updates.

Known issues and status

Check the platform status page before filing a ticket — your issue may already be tracked:

# Status page
https://status.nself.org

# CLI status check
nself cloud status --platform

The status page is updated within 5 minutes of any platform-level incident being declared. Subscribe to RSS or email alerts from the status page to receive notifications automatically.

Sharing logs with support

The fastest way to resolve issues is to include logs in your first ticket. Use the CLI to export a time-bounded log bundle:

# Export the last 2 hours of all service logs
nself cloud logs myapp --since 2h --all-services --output myapp-incident.tar.gz

# Export logs for a specific service
nself cloud logs myapp --service hasura --since 1h

# Export logs since a specific timestamp
nself cloud logs myapp --since "2026-05-01T03:00:00Z"

# Stream live logs
nself cloud logs myapp --follow

Log bundles are compressed and contain Nginx access logs, service stderr, and systemd journal entries. They do not contain your data or credentials.

Quick links

• Getting started — provision your first server
• Billing and subscriptions — plans and payment
• Updates and maintenance — update cadence and rollback
• Provisioning — what happens during provision
• Privacy and data portability — export and deletion
• Cloud CLI reference — all nself cloud commands