Most problems are one of four things: a connection, credits, a provider or a delivery. This page takes them in the order that finds the cause fastest.
Read the state before you retry
Sitearc records what happened to each run, including its last error. Read that first. A retry that ignores it can turn one failure into two.
A connection that stopped working
A provider can revoke access without warning. The site then shows the source as disconnected, not as empty data.
Reconnect under Settings › Connected accounts, or in the site’s own connection settings if it uses a different account.
A paid run that was refused
Paid research shows its cost before it runs. Sitearc holds the credits first, then settles at the measured cost.
A refusal means the hold did not fit your balance or a spending limit. Nothing was bought, so the run is safe to try again later.
At zero credits, paid runs are refused before the provider is reached. Scheduled runs record a skip. Saved data still reads.
Ask your agent to call get_budget_status to see where you stand.
When a provider is down
Sitearc retries a temporary failure a limited number of times. A run that still fails keeps its reason, so you can read what went wrong.
A form response that did not arrive
Check the response in the inbox first. If it is there, Sitearc saved it.
Then read its delivery status: sent, pending, failed or partly sent. Your agent
can check the same with verify_form_receipt.
Reporting a security issue
Email support@sitearc.ai with “Security” in the subject. Please do not post details in public.
What to send support
Send the site, the time in UTC and what you expected to happen.
Never send passwords, API keys or tokens. Support does not need them.