Support & Contact

Before Contacting Support

Most issues have a self-service resolution. Check these first — they are faster than a support ticket and available 24/7.

If you have checked the relevant documentation and the issue is not resolved, contact support.

When to Contact Support

Contact support when:

• You have followed the relevant troubleshooting steps and the problem persists

• You are seeing behaviour that contradicts what this documentation describes

• A container migration fails on startup and you cannot restore from backup

• You need to discuss a deployment architecture not covered in the documentation

• You are evaluating Maestro and need a technical conversation before committing

Do not contact support for:

• Questions answered in this documentation — include a link to the specific page and explain what is unclear, and we will improve the docs

• Feature requests — send these through your account contact; they are tracked in the product roadmap

• Password resets for your GitLab instance — manage those in GitLab directly

Support Channels & SLAs

Response time targets

Response times apply during E-Sharp AB business hours: Monday–Friday, 08:00–17:00 CET/CEST, excluding Swedish public holidays.

For deployments requiring 24/7 support coverage, discuss a premium support agreement with your account contact.

How to Submit a Good Support Request

A well-structured request is resolved faster, requires fewer follow-up questions, and gets to the right engineer on the first contact. The quality of the request directly determines the speed of resolution.

Subject line

Write a specific subject line. Vague subjects slow triage.

Request body structure

Use this structure for every request:

SUMMARY
One sentence describing what is failing and what the expected behaviour is.

STEPS TO REPRODUCE
Exact steps from a clean state that cause the problem. If you cannot reproduce
it reliably, say so — intermittent issues are diagnosed differently.

ACTUAL BEHAVIOUR
What happens. Include the exact error message or unexpected output.

EXPECTED BEHAVIOUR
What should have happened instead.

ENVIRONMENT
(See "What Information to Include" below)

WHAT I HAVE TRIED
Steps you have already taken from the troubleshooting documentation.
This prevents us from sending you back to the same steps.

URGENCY
P1 / P2 / P3 / P4 with a brief explanation of the business impact.

Tone and detail

More detail is always better than less. Do not summarise error messages — paste them in full. Do not describe the problem in general terms when you can paste the exact output. We cannot diagnose "it shows an error" without seeing the error.

What Information to Include

Gather this before submitting. Most of it takes under two minutes to collect and resolves the most common triage questions before they are asked.

Version information

# Running version of all components
curl -s http://localhost:7000/api/health/version | jq .

# Docker image versions currently running
docker compose images

# Docker Compose file version (if you have it)
docker compose version

Paste the output directly into the request.

System health snapshot

# Overall health
curl -s http://localhost:7000/api/health/detailed | jq .

# Station configuration (redact sensitive values before sending)
curl -s http://localhost:7000/api/config/merged/<station-id> | jq .

Container logs

For startup or infrastructure problems, include the logs from the affected container going back to the last restart:

# API logs (most common starting point)
docker compose logs --since 1h api

# Runner logs
docker compose logs --since 1h dotnet-runner
docker compose logs --since 1h python-runner

# Database logs
docker compose logs --since 1h postgres

If the container exited, include the logs before it exited:

docker compose logs api 2>&1 | tail -100

Execution details (for test execution failures)

If the problem is with a specific test run, include:

1. Execution ID — shown in the Test Monitor UI and in POST /api/testexecution/run response

2. Full execution report:

   Bash

   curl -s http://localhost:7000/api/testexecution/<execution-id>/report | jq .
   

3. Execution logs:

   Bash

   curl -s http://localhost:7000/api/testexecution/<execution-id>/logs | jq .
   

4. The YAML file that was running — paste the full file, not a snippet

YAML files (for validation or execution failures)

Always include the full YAML file, not a fragment. Validation and execution errors frequently depend on the surrounding context — fields elsewhere in the file that interact with the failing step.

Environment context

Include this in every request:

What NOT to send

• .env files — they contain passwords. Describe the configuration in words or paste a redacted version

• Database dumps — these contain test data and measurements. Send them only if explicitly requested and through a secure channel

• GitLab Personal Access Tokens — never include these in email

Customer Portal

The E-Sharp AB customer portal is the central place to:

• Submit and track support tickets

• Download Maestro release notes

• Access your GitLab registry credentials

• View your contract and SLA details

Portal: https://help.esharp.se

If you do not have portal access, contact your account manager or email support@esharp.se with your company name and the email address you would like to register.

Sharing Sensitive Information Securely

Test data, execution logs, and YAML files sometimes contain sensitive information (serial numbers, product IDs, instrument addresses). When in doubt:

• Redact values you are not comfortable sharing before pasting into email

• Anonymise serial numbers if traceability to specific units is sensitive

• Request a secure transfer for database exports or large log archives — support can provide an SFTP drop or an encrypted upload link

We do not require real production data to diagnose most issues. A reproduction on a development station with dummy values is preferable to sending production records.

Providing Feedback on Maestro

Feedback about documentation gaps, unexpected behaviour, or friction in the developer experience is genuinely useful and directly influences the roadmap.

If you encounter something that should be documented but is not, or find that documented behaviour differs from what you observe, note it in a feedback.md file in your package repository and include it in your next support contact. You can also email it directly to support@esharp.se with the subject line [FEEDBACK].

Feature requests go to your account contact. They are reviewed against the roadmap in quarterly planning.