Troubleshooting: describe the observed failure
Record what is unavailable: login, one request, file retrieval or the entire portal. A failed page load alone does not establish the cause or scope. Avoid announcing a provider-wide outage without evidence. Note the time and affected action, especially if a submission or payment response was interrupted. That information helps later reconciliation and prevents the team from treating every missing screen as a reason to recreate the same work.
Use the agreed fallback channel
If your agency has an authorized temporary communication route, use it to explain the next practical step. Keep sensitive files within approved storage rather than scattering them through personal accounts. Reference the original request identifier and current accepted version in any interim note. The fallback should maintain continuity, not establish an untracked second system whose comments and commitments will be difficult to reconcile when the portal becomes available again.
Do not replay uncertain actions
Check the original outcome before repeating a charge, submission or invitation. A server may have accepted the action even if the browser never displayed confirmation. Preserve the client’s evidence and the team’s attempt record. If you cannot confirm the state through a supported path, communicate the uncertainty and stop the consequential repeat. This recommendation does not imply that the platform offers exactly-once execution or a guaranteed recovery interface for every action.
Reconcile before returning to normal
When access returns, compare interim work with the original records and resolve conflicts explicitly. Keep useful history rather than overwriting it with the newest copy. Confirm which version and commitment the client should now follow. Review the interruption afterward to improve the continuity plan, but do not invent an uptime or restoration guarantee from a successful recovery. The outcome should be one understandable work trail and a clear account of any remaining uncertainty.
Sources used for this page
These records support the facts and comparisons above. Merchant-controlled records are labelled so you can separate product claims from independent evidence.
- ManyRequests managing requests and exporting data — Merchant documentation · help.manyrequests.com · Merchant-controlled · checked 2026-09-19
- ManyRequests general terms — not a verified affiliate contract — Merchant documentation · manyrequests.com · Merchant-controlled · checked 2026-09-19
- ManyRequests notification email types — Merchant documentation · help.manyrequests.com · Merchant-controlled · checked 2026-09-19