To report a Star Citizen gameplay bug, describe the ship behavior you observed and give enough detail for someone else to reproduce it. Keep the report focused on what happened, rather than guessing at the cause.
A useful report turns a confusing symptom into a clear, repeatable example. For instance, describe a specific ship behavior you can trigger again, not a theory about which component or system is responsible. That gives other players a concrete issue to understand and assess. [1]
This section focuses on reporting the symptom, not diagnosing it or walking through repairs. Keep those separate: a report should capture the behavior you experienced, while troubleshooting and repair steps belong elsewhere. When you are ready, make the observed problem easy to understand and reproduce; the sections below explain what details to capture and how to present them.
What to record before you open a report
Record the game build, ship, location, and conditions around the symptom before you open a report. Those details give other players useful context when they try to follow your account; for example, note whether you were in a particular ship at a landing pad or during a mission.
Capture the lead-up
Write down what you did immediately before the problem appeared. Keep the sequence concrete: if the issue started after you powered up the ship, changed seats, or entered a particular area, record those actions in order rather than summarizing them as “it happened during flight.”
Include relevant conditions that might help someone repeat the event, such as the ship’s state or what was happening nearby. Avoid filling the report with details that do not connect to the symptom; a focused account is easier to follow.
Make the reproduction specific
Describe the exact actions and conditions needed to reproduce the issue. For example, identify the starting situation, the action you take, and the point at which the symptom appears. Be precise about timing when it matters, such as whether the behavior begins immediately or only after another action.
Keep the account limited to what you observed. Don’t add a theory about the cause unless you can verify it, and leave unrelated problems for separate reports. A clear record of the build, setting, and steps is more useful than a long list of guesses.
Before submitting, review your notes and remove details that don’t help someone understand or repeat the behavior. Then use the current official reporting channel to submit the report; the Issue Council guidance describes reporting a new issue when you can’t find an existing one. [2]
How to write steps another player can follow
A useful reproduction list lets another player recreate the same ship behavior without guessing what you did. Start with the ship and setting, then give each action its own numbered step and finish with the expected and observed results.
Set the starting state. Name the ship and describe where it is and what it is doing before the symptom begins. For example: “I’m in a Freelancer in the hangar, seated in the pilot’s chair, with the ship powered on.”
List the actions in order. Put one action in each step, and include timing or conditions that matter. For example: “1. Open the landing gear controls. 2. Wait until the gear animation stops. 3. Press the takeoff control once.” Avoid bundling several inputs into one step; a reader should be able to follow the sequence as written.
Say what should happen. Give a concrete expected result in its own sentence, such as: “The landing gear should retract after the takeoff input.”
Say what actually happens. Keep the observed result separate: “The gear stays extended, and the ship remains on the pad.” Describe what you saw rather than explaining why you think it happened.
Report the repeat result. Say whether the same sequence produced the same symptom when you tried it again. If the result changed, state what was different or that it did not recur; don’t present a one-time result as repeatable.
Keep the steps focused on one behavior. A simple sequence with a clear start, individual actions, and two distinct outcomes is easier for another player to test than a long paragraph that mixes several things together. Similarity to existing Issue Council reports can help you compare how other players describe their steps [1].
When screenshots, clips, or another test help
When screenshots, clips, or another test can clarify a ship bug, keep the evidence focused on the behavior you are reporting. A short clip of a ship refusing to respond to an input, for example, can make the symptom easier to understand than a long recording of an entire play session.
Capture the useful moment
Attach a screenshot or clip if you have one that shows the symptom or relevant context. A screenshot might show the ship and the unexpected result; a brief clip might show the action followed by the result. [2]
Keep the capture tight: include enough to make the behavior clear, but leave out unrelated gameplay. If the symptom only becomes clear through a sequence, trim the clip to that sequence rather than adding footage that does not help explain the report.
Test the same actions again
If it is practical, repeat the same actions and check whether the same result occurs. For example, if a ship does not react after a particular input, try that same input sequence again and note whether the response is consistent. [1]
If the result changes between attempts, say so plainly. Do not describe the bug as consistently reproducible when you have seen it only once or when repeats produce different outcomes; an honest account of a one-time occurrence is more useful than overstating what you observed.
Evidence should support the report, not replace its explanation. Use a clip to show the relevant behavior, then make sure your report’s written steps and outcome tell the reader what to look for. If you do not have a useful screenshot or recording, focus on describing what happened accurately rather than adding unrelated evidence.
Check for a similar report, then submit yours
Search Issue Council for a report with symptoms like yours before you create one. Issue Council guidance recommends looking for reports that behave similarly and searching with relevant keywords. [1] For example, if a ship’s landing gear stays extended after you retract it, search the ship’s name alongside terms such as “landing gear” and “stays extended.”
Try a few descriptive keywords tied to the ship or the behavior you observed. [1] A search for a ship name alone may be broad, so pair it with the symptom—for instance, “Cutlass ramp won’t close” or “Constellation turret not responding.” If the first wording brings up no useful matches, try a shorter symptom phrase or a different term for the same behavior.
If you find no matching report, use the current official Issue Council process to submit a new issue. [2] The official guidance directs players who cannot find an existing report to the “Report a New Issue” option from the Dashboard. [2] Before submitting, make sure you are describing the same behavior you searched for, not bundling in a separate ship problem. A report about a ramp that will not close should stay focused on that symptom rather than also covering an unrelated weapon issue.
If a similar report already exists, use its available contribution options instead of creating a duplicate. Similar reports may not be exact matches, so compare the described behavior and circumstances before deciding. For example, two reports involving a ship door may describe different symptoms; contribute to an existing report only when it matches the behavior you observed. If you do not see an option that fits, check the current Issue Council interface for the available next step.
Once you have checked for a match, either contribute to the relevant existing report or submit a new issue through the official Issue Council process. Keep the choice tied to whether an existing report describes your symptom, rather than creating a second report simply because your search used different wording.
Common reporting mistakes to avoid
A focused report is easier to assess than one that bundles several ship problems together. Keep each report to one symptom: if your ship’s landing gear fails to retract and its weapons also stop firing, describe those as separate issues rather than treating them as one broad failure.
Describe behavior, not a label
Avoid shorthand such as “the ship is broken.” That phrase does not tell another player what to look for, so replace it with the specific action and result—for example, “I press the landing-gear control, but the gear stays extended.”
Keep the wording neutral and concrete. A concise description of what you did and what followed gives readers a behavior to compare, instead of asking them to interpret a vague judgment.
Keep observations separate from theories
Write down what you saw, then keep any guess about why it happened out of the report’s factual description. For example, say that a weapon did not fire after you pressed its control; do not state that a damaged component caused the failure unless you verified that connection.
This distinction helps prevent a theory from being mistaken for an observed result. If you are unsure about the cause, leave it unstated and let the reported behavior stand on its own.
Be honest about one-time incidents
Do not describe a single, unrepeated incident as a reliably reproducible bug. A symptom that appeared once may still be worth reporting, but describe it as a one-time occurrence rather than implying that others can trigger it consistently.
Before submitting, check that the report covers one symptom, uses concrete wording, and separates what happened from what you suspect. Then submit it through the current official reporting channel.
Put the report together and submit it
A useful bug report gives the team enough detail to understand the behavior and try it for themselves. Before submitting, gather the game version, ship, location, your reproduction steps, what you expected to happen, and what actually happened. Add a focused screenshot or clip if it helps show the symptom or its context.
For example, note the build you were playing, the ship involved, and where the behavior occurred. Then describe the actions in order, such as entering the ship, starting it, and trying a particular control. State the expected result separately from the observed result; keep the report focused on the one behavior you reproduced.
Submit a focused report
Before creating a new issue, search Issue Council for a report describing the same behavior. If you do not find a match, the official guidance directs you to report a new issue from the dashboard search area or its available reporting option. [2] If you find a similar issue, use the contribution options available on that report instead of creating a duplicate.
Keep the wording factual: describe what you did and what happened, without guessing at the cause. If you only saw the behavior once, say so rather than presenting it as reliably repeatable. A short, ordered report with relevant evidence is easier to act on than a long account mixing several symptoms.
Your next step is to assemble those details, check for a matching report, and submit through the current official channel. Stick to the behavior you actually reproduced, and make clear what you expected to happen versus what you observed.