Support
This page is for someone whose own site, database or domain on juudd is not doing what they expected. If you are reporting a juudd-hosted site that belongs to someone else, that is a different page.
Two places that answer before we do
- The refusal itself. When a tool refuses, it answers with the reason in a sentence, and that sentence is kept. Ask your assistant to call list_refusals and it will read back every refusal on your account with the wording each one was given. Most questions that reach a mailbox are already answered there, in the words of the call that failed.
- The panel. It shows your account's own sites, versions, databases, domains and the record of every action taken on them. It shows one account — yours — and nobody else's.
Where to write
alongkot.sa@mattrek.co. A person reads it. It is the same address the privacy policy and the terms name, and the same address that handles deletion requests and requests under Thailand's PDPA.
If you have found a vulnerability in this platform rather than a problem with your own account, security@juudd.com is the address for that.
What to include
One message can be acted on in a single pass if it carries these.
- The site id, or the URL you are looking at. It is what names the thing to be looked up.
- What you asked your assistant to do, and what came back. If it was a refusal, its exact sentence.
- When it happened. Every action and every refusal is written down with a time, so a time is what finds it.
What we can do
- Read the record. Every write and every refusal on your account is stored permanently, with the account, the action, the site and the outcome. A question about what happened has an answer that was written at the time rather than reconstructed afterwards.
- Put back an earlier version. Every version you have ever deployed is kept, permanently and on purpose. Going back is publishing an older version, not restoring one, so it is one act and it returns exactly what was live.
- Remove your identity records and action history on request. A self-serve path for it is not built yet; write to the address above and it is done by hand. The privacy policy says the same thing and is the document that governs it.
What we cannot do
- Read a database we have handed over. After transfer_database the database is in your own account and this platform has no access to it at all. That is the point of the tool and it has no undo: support cannot look inside, back it up, or get it back.
- Recover a credential. A site's database password exists in one place, a write-only binding on the deployed site. We cannot read it back, so we cannot tell you what it is — reset_database_credential rebuilds one rather than recovering it.
- Delete a deployed version. Versions are permanent, which is what makes a rollback possible and is promised to you. Stopping a site from being served is a separate thing and is available; erasing what was served is not.
- Answer a billing question. There is nothing to bill yet. Payments are not live, nothing is charged, and the terms will be updated before that changes.
What happens next
The address reaches a person, not a queue. Anything done to your account in the course of answering is written into the same permanent record you can read yourself, naming the operator who did it — so a decision made about your account can be read back later, by us or by you.