Skip to content
English
Customer portal
Contact us
  • There are no suggestions because the search field is empty.

12.05 When to Contact Support

SimpleRisk has multiple support channels. Use the SimpleRisk paid support team (for paying customers) for production-impact issues, configuration help, and incident response. Use GitHub Issues for bugs and feature requests on the open-source product. Use the SimpleRisk community forum for general questions. Pick the right channel; provide good context; respect the response-time expectations.

Why this matters

A SimpleRisk install in trouble is unpleasant. The instinct is "contact support immediately and let them fix it." Sometimes that's right; sometimes the same issue would be resolved faster by checking the documentation, searching the community forum, or running through the Troubleshooting Common Issues playbook. Knowing when to escalate to support (and how to make support effective when you do) saves time on both sides.

This article covers the channels, when to use which, and what to include in a support request to get fast resolution.

Support channels

SimpleRisk has several channels:

1. SimpleRisk Paid Support

For customers with a SimpleRisk Hosted, Premium, or other paid plan. Reach via:

  • Support portal — typically the standard ticketing surface; check your contract for the URL.
  • Email — the support email address provided with your contract.
  • Account manager — for relationship-level escalation.

Use for: - Production outages or significant operational impact. - Incidents requiring fast response. - Configuration help for paid features (Hosted-specific operations, Extras you've purchased). - Architectural advice for your specific environment. - Integration help for non-trivial integrations. - Anything where your contract entitles you to direct support.

Response time: per your contract's SLA. Typically business hours; some contracts include 24/7 for critical issues.

2. GitHub Issues

For the open-source product. Reach at https://github.com/simplerisk/code-development/issues.

Use for: - Bug reports: reproducible bugs in the SimpleRisk codebase. - Feature requests: features you'd like to see in future releases. - Documentation issues: errors or gaps in the public documentation. - Open questions about the codebase that may benefit other operators.

Don't use for: - Customer-specific configuration questions. - Production outages requiring fast response. - Anything containing sensitive content (issues are public).

Response time: best-effort; SimpleRisk's open-source community responds when they can. Paid customers shouldn't rely on GitHub for production support.

3. Community Forum

The SimpleRisk community forum (URL on the SimpleRisk website) is for peer-to-peer help.

Use for: - General questions about how to use SimpleRisk. - "Has anyone done X" patterns and best practices. - Discussion of features, workflows, or integration patterns. - Connecting with other operators running similar deployments.

Don't use for: - Anything containing sensitive content (the forum is publicly visible). - Production outages.

Response time: variable; community-driven.

4. Documentation

The customer-facing HubSpot KB (which is what this article is part of, for customer-facing distribution) and the GitHub user_guide/ and admin_guide/ directories.

Use for: - Standard "how do I do X" questions. - Reference (configuration settings, schema, API). - Onboarding new operators.

Always check before contacting support: most "support questions" are documented.

When to escalate

The escalation path:

  1. Self-help: documentation, Troubleshooting Common Issues, GitHub Issues search, community forum search.
  2. Community: post in the forum; search for similar questions.
  3. GitHub Issues: file a bug or feature request if appropriate.
  4. Paid support: when the above haven't resolved and you have paid support entitlement.

For production-impact issues with paid support: skip the lower steps and contact support directly. The cost of waiting on community response when production is down is too high.

How to make support effective

A well-written support ticket gets resolved faster than a poorly-written one. Include:

What's broken

  • Specific symptom: "Users see 500 errors when submitting risks" beats "the system is broken."
  • What's not affected: "Logins work; risk list view works; submission fails." This narrows the search space.
  • When it started: "Started at 14:30 UTC today" or "After we upgraded last weekend."
  • How often it occurs: every time, intermittently, only for certain users.

Reproduction steps

If the issue is reproducible:

  1. Step-by-step reproduction in a non-admin account.
  2. Specific data that triggers the issue (anonymize sensitive content).
  3. Expected vs actual behavior.

If not reproducible: explain the conditions that triggered the most recent occurrence.

Diagnostic information

  • SimpleRisk version: from version.php or the about page.
  • Active Extras: list which Extras are activated.
  • PHP version: php --version.
  • Web server and version: nginx -v or apache2 -v.
  • Database version: mysql --version.
  • Operating system: cat /etc/os-release.
  • Deployment mode: bare metal, Docker, cloud-hosted, etc.

Logs

The most useful artifact:

  • Debug log entries around the time of the issue. Filter for the time window; sanitize sensitive content; attach.
  • Web server error log entries.
  • Database error log if relevant.
  • Specific stack traces if PHP errors are involved.

Don't paste 10,000 log lines; trim to the relevant entries with brief context (5-10 lines before and after the issue).

What you've tried

Save support time by listing what you've already attempted:

  • "Restarted PHP-FPM — no change."
  • "Verified database connectivity — works."
  • "Checked the cron is running — yes, last run was 14:00 UTC."

This prevents support from suggesting things you've ruled out.

Severity / impact

For paid support: indicate the actual impact:

  • Critical: production down, no workaround, urgent.
  • High: significant degradation, workaround exists.
  • Medium: specific feature broken, low-impact users affected.
  • Low: cosmetic, non-blocking, or in non-production.

Honest severity gets right-sized response. Marking everything as Critical produces inattention to actual Critical issues.

What support typically needs

Be ready to provide on request:

  • Database access (read-only) for diagnostic queries.
  • OS-level access for log inspection or process status.
  • Permission to make configuration changes in your install (with your approval per change).
  • A non-production environment to reproduce and test fixes.
  • Time for back-and-forth: support will ask questions; respond promptly.

What support typically doesn't do

Setting expectations:

  • Customizing your install beyond what's covered by your support contract.
  • Writing custom code for your integrations.
  • Recovering data that was lost without backups (the encryption key file specifically).
  • Architectural redesign beyond what's contracted.
  • Long-term operations of your install (paid support helps with issues; doesn't run the install for you).

For these needs, SimpleRisk's professional services or a qualified partner is the path.

Common pitfalls

A handful of patterns recur with support requests.

  • Reporting "it's broken" without specifics. Support can't help without information. Provide what's listed above.

  • Reporting after extensive failed self-debugging without documenting what you tried. Support starts from scratch on the same paths you've already exhausted.

  • Filing a GitHub issue for a paid-customer-specific question. Use the appropriate channel.

  • Using the community forum for sensitive content. Forum posts are public; sensitive content stays in support tickets.

  • Filing multiple tickets for the same issue. Confuses tracking; respond on the existing ticket.

  • Marking everything as Critical. Loses signal value when something actually is.

  • Not responding to support's questions. Tickets stall waiting on you.

  • Treating support as the primary documentation source. Documentation exists; check it first.

  • Not implementing support's recommendations. A recommendation that's not followed isn't a fix.

  • Filing a feature request as a bug. Bugs and feature requests have different prioritization paths; categorize honestly.

  • Filing a bug for behavior that's actually documented. Read the docs first; if the docs are wrong, file a documentation issue.

  • Sharing API keys, master encryption keys, or passwords in tickets. Treat as you would any other sensitive credential. Support shouldn't need them; if they do, share via a secure channel.

Related

Reference

  • Paid support contact: Per your contract — typically a support portal URL and an email address. Check the support documentation provided with your subscription.
  • GitHub Issues: https://github.com/simplerisk/code-development/issues.
  • Community forum: URL on the SimpleRisk website.
  • Public documentation: Customer-facing KB (HubSpot) and the user_guide/ and admin_guide/ directories in the open-source repository.
  • Codebase: https://github.com/simplerisk/code-development.