Hello, I’m Nora, your AI guide from Technology Last Stop. This guide covers Verify scheduled maintenance actually runs. Distinguish a manual operation, an installed handler, a recorded hosting invocation and confirmed provider delivery. Current availability: Invocation recording implemented; production schedule evidence must be observed.

Before you start. A verified TLS owner and a hosting schedule configured for the production worker. The current additive scheduler_runs migration and access to the owner company environment panel.

Step 1. Open a company’s Licenses & billing > Configuration replicas & recovery > Hosting scheduler evidence. This owner-only view shows up to five observed invocation start times, completion times and results.

Step 2. Wait for a hosting-generated invocation. The scheduled handler records its start, runs the existing maintenance tasks plus configuration replica processing, then records completed or partial failure. Manual Run now does not create a hosting invocation record.

Step 3. Review partial failures using protected operational records. One failed maintenance task does not stop the other tasks. The summary stores task names and outcomes, without provider secrets or response bodies.

Step 4. Check the actual intended result separately: a group snapshot progressed, an operation received its matching receipt, or an approved recipient received a renewal notice. A completed handler is not proof that an external message was delivered.

Step 5. Recheck after a hosting or runtime change. Invocation summaries are retained for 14 days and cleaned during successful maintenance. Keep required audit evidence in the approved records system before the local observation window expires.

Now verify the result. An actual hosting invocation has a recorded start and finish. An empty view explicitly says no invocation has been recorded. Dev, QA and registered company replica targets do not run production maintenance. Independently hosted monitoring must detect missing heartbeats and outages; the portal cannot prove its own availability during a host failure.

If you get stuck. No recorded invocation: verify the production hosting schedule and deployment configuration. Do not label reminders or automatic processing operational based solely on source code. A running record without a finish may indicate interruption or runtime failure. Review hosting logs and each idempotent task’s state before retrying. Provider delivery failures still require the correct customer consent, credentials and approved recipient. Scheduler evidence does not replace that setup.

Use the current written guide for exact URLs, permission names, and provider documentation. Pause before entering credentials, and keep them in protected configuration. I’m Nora, your TLS guide.