You hit a wall at 4:45 on a Friday. A user cannot sign in, the error is some cryptic string you have never seen, and the steps you took to get there are already fuzzy in your own memory. You open a request, type "sign-in is broken for one user," and hit send. Then you go home.
Monday morning, the reply is waiting: "Can you send a screenshot of the error? Which user? What were they trying to open?" Now you are reconstructing Friday from memory, the user is reconstructing it from theirs, and the actual fix has not started yet. Two business days gone, and not one of them spent solving the problem.
The thing that would have saved both days was sitting on your screen the whole time: the error, the window behind it, maybe a 20 second recording of the click that triggered it. Attachments are not busywork. They are the difference between a request we can act on immediately and a request that turns into a week of email tag. Here is what helps, and the two kinds of files that should never go anywhere near a ticket.
What helps us move faster
The best attachment answers a question before we have to ask it. When you open a request in the portal, the intake form has a Supporting evidence area; you can drag files straight in or click to pick them. You can also add files to the updates thread of any request later, which is where most clarifying screenshots end up.
A few things earn their place every time:
- Screenshots of the exact error, with enough of the surrounding window to show what you were doing when it appeared. A cropped error code with no context makes us guess; the full window does not.
- Short screen recordings, roughly 10 to 60 seconds, for anything easier to show than describe. A recording of the click that breaks sign-in tells us more than three paragraphs trying to narrate it.
- Log files from the affected app, when you can find them. If you cannot, say so in the description and we will point you at where they live.
- Configuration exports when we are debugging permissions or settings in a SaaS app, so we are reading your real setup, not a description of it.
You do not have to gather all of this. One clear screenshot is often enough to start. The goal is simple: give us enough to reproduce the problem on the first read, not the third.
The two files that should never touch a ticket
Most of what you might attach is fine. Two categories are not, and the reasons matter more than the rule.
The first is secrets: passwords, API keys, tokens, any live credential. A ticket is a durable record. It gets read by the people working your request and it stays attached to the request as history. A password pasted into that record is a password you now have to treat as exposed. If we ever need a credential rotated, we will ask you to rotate it on your side; we never need the secret itself sitting in a thread.
The second is protected health information (PHI). If your organization touches PHI under the Health Insurance Portability and Accountability Act (HIPAA), it does not belong in a support request. Cloud Sentry does not accept PHI through the support portal. This is not us being difficult: it is a boundary that keeps both sides clean. You can almost always describe the problem without the patient data. A redacted screenshot, a fake example record, a description of the broken behavior with the sensitive fields blacked out: all of these let us help without putting regulated data where it should not be.
There is a quieter third case worth naming. If you accidentally saw another company's confidential data, describe what you saw without re-attaching it, and we will guide you on reporting it properly.
The limits, in plain numbers
The portal takes the file types you would normally share with any support team: images, PDFs, Office documents, plain text and structured data like CSV and JSON, log files, archives, and common audio and video formats. The ceilings are generous but real:
- Up to 10 files per request.
- 25 MB maximum per file.
- 100 MB maximum across everything in the request.
If what you have is bigger than that, mention it in the description and we will point you at a better path. Executables, scripts, and SVG files are not accepted directly; if you genuinely need to send one, drop it in a ZIP with a short note on why. None of this is meant to slow you down. It is meant to keep the channel safe and the uploads predictable.
Why this is an operating habit, not a rule
The reason a good attachment matters is the same reason a small team can run like a much larger one: the work moves to whoever can act on it, with nothing missing. A request with the right screenshot gets solved on the first pass; a request missing it bounces back for detail. Multiply that across a year of tickets and you have bought back days you did not know you were spending.
Security lives in those same small habits. Keeping secrets and PHI out of a ticket is not a compliance checkbox; it is how the channel stays trustworthy enough that you can move fast inside it. The teams that get the most out of us are the ones who treat a request like a handoff: here is the problem, here is what I saw, here is the evidence, go.
So next time something breaks at 4:45 on a Friday, before you close the laptop: what could you capture in 30 seconds that would let the fix start without you?