Get useful support quickly

Before you start

For an active pilot, use the contact and coverage agreed at handover. For a new pilot or general question, use the website inquiry form or hello@clusterpilot.de. The sales inquiry response message is not an incident-resolution SLA.

Lead with impact, then evidence

A useful first sentence identifies the application, affected users and start time: for example, “Test checkout returns 503 for all test users since 09:15 UTC after release X.” Separate the observed impact from a suspected cause. Say whether the service is fully unavailable, partially degraded or a non-urgent question.

• ✓
  Include the pilot identifier and an application contact who can verify the result.
• ✓
  Use timestamps with a timezone and list the last relevant deployment or configuration change.
• ✓
  Share the exact error and what a bounded check showed; note what has not yet been checked.

Use this support brief

Subject: Cloud pilot · [project] · [brief impact]
Pilot/project identifier:
Contact and availability:
Affected organization / workspace / cluster / application:
Started (date, time, timezone; preferably UTC):
User impact and affected functions:
Last relevant change:
Expected behavior:
Observed behavior / exact error:
Checks already performed and their results:
Short redacted evidence (no credentials / personal content):
Available recovery path and pending decision:

Fill in only what is relevant. Paste the brief into the agreed pilot channel or the website's message field for a general inquiry. This template does not open an automatic support ticket by itself.

Keep diagnostics minimal

The inquiry form requires acknowledgment of the privacy notice and does not enroll you in marketing. Avoid personal application data in the message. Keep your own change and incident record so you can correlate a later response.

Close the loop after a fix

Confirm who owns the next action and when an update is expected within the agreed support terms. After a change, repeat the application's failing journey and record the result. Capture the cause, the fix, remaining risk and a prevention task where useful. Keep infrastructure actions and application acceptance separate so an operation marked complete does not mask a continuing user problem.