Kutt customer service — professional guide for users and operators

Overview: how Kutt support is organized (hosted vs self‑hosted)

Kutt is primarily an open‑source URL shortener (source: https://github.com/thedevs-network/kutt) and a hosted service at https://kutt.it. That dual model determines customer service channels: the community and repository maintainers handle bug reports, feature requests and installation help for the open‑source project; the hosted service operator handles account‑level issues, abuse, billing and uptime for kutt.it customers. There is no widely advertised public telephone support for the project — support is asynchronous and trackable via GitHub issues, discussion threads and the hosted service’s contact form or support email (see project README and hosted site footer for current contact links).

For operators who self‑host Kutt, support responsibility shifts to the system administrator or third‑party managed provider. Typical Kutt deployments in production run Node.js (current recommended LTS), a PostgreSQL database for link and user data, and HTTP termination via Nginx or a managed load balancer. This means common support tasks require skills in Node.js process management, PostgreSQL backups and DNS/SSL configuration.

Primary support channels and response expectations

Where to open issues: the canonical place for code bugs and enhancement requests is the GitHub repository at https://github.com/thedevs-network/kutt — open a new Issue with a clear title and reproduction steps. For account or billing questions about the hosted instance, use the contact methods on https://kutt.it (support form or hosted account dashboard). Community discussion may also happen on GitHub Discussions or a linkable forum referenced in the project README.

Response time varies by channel: community maintainers typically triage new GitHub issues within 24–72 hours; critical security reports should be handled via a private channel if one is specified in the repo. If you need SLA‑level support (response in < 1 hour, guaranteed uptime), plan to purchase a managed support contract or retain a consultant — community support is not an SLA.

Troubleshooting: common problems and exact checks

Custom domain and DNS issues are among the most frequent operational problems. Verify the custom domain uses a CNAME (or ALIAS/ANAME for root domains) that points to the hosted endpoint, or points at your load balancer IP if self‑hosting. Check DNS propagation with tools such as dig or https://dnschecker.org; TTLs and DNS caching mean changes can take minutes to hours. For SSL problems, confirm that an ACME/Let’s Encrypt process is running or that your certificate files are present and unexpired (openssl s_client -connect example.com:443 -servername example.com).

Application errors manifest as 502/504 or 500 responses. Collect these diagnostics first: Kutt server logs (stdout/stderr from the Node.js process or container logs), Nginx/error logs, PostgreSQL error logs, and system metrics (CPU, memory, file descriptors). Common causes: exhausted DB connections (raise pool size or tune max_connections), missing environment variables (check .env or Docker Compose), or Redis/queue unavailability if used. For rate limiting or API quota errors, reproduce a single failing API call with curl and include the response headers in your report.

How to file a high‑quality support request (checklist)

• Reproduction steps: exact sequence, example short URL, API payloads, and curl commands that reproduce the issue.
• Environment snapshot: Kutt commit or release tag (GitHub SHA), Node.js version (node -v), PostgreSQL version (psql –version), deployment mode (Docker Compose, Kubernetes, VPS), and operating system (name + kernel).
• Logs and error excerpts: paste relevant lines with timestamps (last 200 lines), Nginx/Proxy logs, and any stack traces. Remove sensitive tokens but preserve error codes.
• Configuration: sanitized .env values (list keys without values), custom domain records (output of dig +short), TLS certificate expiry date (openssl x509 -noout -dates -in cert.pem).
• Impact and priority: number of affected users, business impact, whether it’s reproducible for all requests or intermittent, and desired timeframe for resolution.

SLA, uptime math and managed support pricing guidance

If you require guaranteed availability, negotiate an SLA. Common targets and the equivalent downtime per month are: 99.5% → ~3.65 hours/month; 99.9% → ~43.2 minutes/month; 99.99% → ~4.32 minutes/month. Use these numbers to set monitoring alerts and incident windows for restorative action.

• Typical managed support tiers (market guidance): Basic monitoring & weekly maintenance: $30–$150/month. Standard support (8×5 email/ticket, 4‑hour response P1): $300–$1,200/month. Enterprise (24×7, 1‑hour response, on‑call, runbooks): $1,500+/month or custom retainer—consultant rates for emergency troubleshooting often run $75–$250/hour depending on region and expertise.

Incident response, monitoring and metrics to track

Implement automated monitoring: uptime probes (1‑minute frequency), application error rate, HTTP latency p50/p95/p99 targets (aim p95 < 200 ms; p99 < 500 ms for small deployments), database slow queries, and connection pool utilization. Configure alerts to a pager or Slack with escalation rules so that a P1 incident (total outage) triggers an immediate phone or SMS alert.

Post‑incident, record MTTR (mean time to recovery) and root cause. Aim for MTTR under 60 minutes for critical incidents for paid support; for community support, document the incident and the reproducible steps so maintainers can triage later. Keep backups of PostgreSQL WAL and daily dumps; test restores quarterly to ensure RTO/RPO goals are realistic.

Security, compliance and privacy practicalities

Short links carry abuse risk (malware, phishing). For hosted or self‑hosted Kutt, include abuse reporting and takedown procedures in your customer service flow. Log link creation IPs and timestamps for investigations and retain logs according to your privacy policy and local law (GDPR, CCPA). If you process EU personal data, publish a data processing addendum and ensure you can purge user data on request.

For production deployments, enforce HTTPS everywhere, rotate admin credentials regularly, and run dependency vulnerability scans (npm audit, Snyk). For critical vulnerability disclosures, follow responsible disclosure: provide a private channel, issue a patch, and communicate timelines to affected users.