Contact us
Use the contact form for anything: a bug, a question about what Spek does, or a disagreement with something the agent proposed.
If you are signed in, the Feedback option in the sidebar reaches the same place and carries a bit of context about where you were.
What to include
ASO problems are almost always specific to one market, so a report without one is hard to act on. Four things make the difference.
- The app and the market. Which app, which storefront, which language.
- What you expected and what happened. A proposal you think is wrong is more useful with the reason you think so.
- When. Roughly when you ran it, so we can find the run.
- A screenshot, if something looked wrong on screen.
Checking for an outage
Before reporting something broken, check status.spek.app. It is hosted separately from the app, so it stays up when Spek does not, and it shows current incidents and component health.
If an incident is already open there, it is already being worked on and you do not need to write in.
Common questions
How quickly will I hear back?
Faster with the app, the market and roughly when it happened. Those three turn a report into something we can look up.
Describe the issue clearly and include any safely shareable error message. If a service incident matches the problem, the status page provides the published operational updates. Do not assume a fixed response deadline from this guide; the important first step is giving the team enough context to investigate.
Can I send my key so you can reproduce it?
No. Never send a private key or a password. A key ID or an issuer ID is all we would need.
How should I report a proposal that seems wrong?
Identify the app, store, market and field, then explain the product fact or language issue that makes the proposal unsuitable. A specific explanation, such as a feature the app does not offer or wording that changes meaning locally, is more useful than a general statement that the suggestion is bad. Include the approximate run time and a safely shareable screenshot if helpful. You can keep or revise the current draft while the issue is investigated; reporting a proposal does not require publishing it first.
How should I report a publish that may have partially succeeded?
Name the app, version and intended locales, and include the outcome displayed by Spek. Say which values you verified in the provider and which remain uncertain. If a recovery or reconciliation action is available, follow the documented guidance rather than repeatedly issuing the publish command. Partial results need the successful and failed scope kept clear. Never send store credentials as evidence. A precise account of the first operation helps the team investigate without confusing it with further attempts.
What should I remove from a screenshot before sharing it?
Remove passwords, private key contents, authentication tokens, payment-card details and unrelated private customer information. Keep the app or workspace context, visible error and relevant control readable when they are safe to share. If the issue concerns a private draft, include only the portion needed to demonstrate the problem. A screenshot is supporting evidence, so accompany it with the market, approximate time and a short description of the expected result instead of relying on the image to explain every part of the task.
Can I report an individual issue when the status page is healthy?
Yes. The status page describes shared service availability, while an individual app can have a credential, permission, version-state or data issue. Check for an incident that matches your symptoms, then contact support if the problem is specific to your account or is not explained by the published update. Include the affected app and market and whether other parts of the workspace work normally. A healthy shared service check does not certify that every store action for every account can succeed.