The cutover is complete. Your site resolves, pages load, and the launch call ends. Over the following days, the questions become more specific: whether an integration still works, why a rule is matching a new request pattern, and how an upcoming release should be reflected in the configuration.
Your team should be able to see progress through those questions. A month of operation should produce evidence that the deployment fits the application and that the people supporting it can make sound decisions.
Each week below has a practical focus and something concrete for your team to review. Urgent issues still come first, and essential contacts must exist from day one. The weekly rhythm structures the rest.
Week one: establish what is working
Begin with the services and customer journeys that mattered at cutover. Review production hostnames, intended traffic paths, TLS behaviour, and access to the application. Check critical integrations alongside browser journeys.
Ask the application team to validate the actions that represent useful service: signing in, submitting a form, completing an order, or receiving an API response. Choose the actions relevant to your application.
Review security events alongside that testing. Early rule matches may represent expected enforcement, false positives, or traffic that needs further investigation. Preserve those distinctions in the record.
Your team should receive a short stabilisation note containing the journeys checked, any failures or uncertainties, and the action assigned to each open issue. Include who performed the check and when, so later changes do not make an old result look current.
Temporary configuration deserves attention here. If the launch used an exception or workaround, record why it exists, what would allow its removal, and who will review it.
The useful end-of-week outcome is a shared understanding of service health, with open issues visible and actionable.
Week two: make routine changes easier to handle
Go-live should already have established emergency contacts and change authority. During the second week, test whether those arrangements work for the ordinary requests now arriving.
Take a real upcoming change, such as a new campaign hostname or an application release affecting a protected route. Follow it through preparation, approval, implementation, and verification.
Check where the request belongs and what information the operator needs. Identify who can explain the application behaviour, who approves the security impact, and who confirms the result from the customer side.
Your team should see a usable contact and change record. It should include a fallback for unavailable approvers and a clear escalation route for incidents. Avoid relying on one person’s memory of the launch call.
Also confirm where configuration is managed. If automation or infrastructure code controls part of the account, the operational process needs to respect that source and keep emergency changes reconciled with it.
By the end of the week, a colleague who missed the migration should be able to submit a change and understand how it will be handled.
Week three: tune with application evidence
The third week provides an opportunity to review the traffic observed so far. Treat it as an early sample. A quiet launch period may not represent a promotion, billing run, or major release.
Review WAF actions, bot-related events, rate limiting, and other relevant controls against known application behaviour. Ask support and application teams where users or integrations have experienced friction.
Select adjustments with a clear reason. For each proposed change, record the evidence, intended effect, scope, and verification method. Keep unrelated changes separate enough that their effects remain understandable.
Your team should see a tuning record that connects each adjustment to an observed issue or a defined requirement. “Updated rules” gives a reviewer little to assess. “Adjusted the identified rule for this confirmed integration request, then verified the callback” explains the work.
Review early exceptions during the same period. Some may now be removable; others may depend on application work. Give unresolved items a next action.
Where the evidence does not support a change, record that conclusion. Useful tuning includes leaving a control in place after checking its behaviour.
Week four: verify how the team responds
Use the final full week to exercise a realistic incident scenario. A tabletop walkthrough is often enough to reveal gaps without generating disruptive traffic.
Choose a scene grounded in your application: support reports a blocked form after a release, an API route starts returning errors, or a DNS change appears to have sent traffic to the wrong destination.
Have the people involved work through the response. Establish where they would find recent changes, how they would correlate the report with available events, and who would approve an urgent adjustment.
Then inspect the recovery step. Confirm that the previous configuration is recorded and that rollback would account for any subsequent changes. Check how the team would verify the application result and communicate it to support.
Your team should receive an exercise note with the decisions tested and the gaps found. Turn those gaps into assigned actions. A missing contact, inaccessible log, or unclear verification step is a useful finding when it is resolved before a live incident.
Days 29 and 30: agree on the next operating priorities
Bring the month’s records into one review. Show what has been verified, what changed, what remains uncertain, and which temporary measures still need attention.
Agree on priorities using the application’s upcoming calendar. A campaign, new integration, or architecture change may matter more than a low-impact configuration cleanup.
Keep the review readable. Your team should leave with a current view of service health and a short set of owned actions, supported by the detailed records when someone needs them.
If you want the operator-side picture of how Vigilbase runs the account after go-live, start with How we run Cloudflare after go-live, then Who operates Cloudflare after go-live and Managed Cloudflare. This post is the buyer-facing evidence pack your team should be able to show; those pages cover the operating model behind it.
Vigilbase sells the Cloudflare licence and operates the account after go-live. In the first month we build this working evidence with your team, so later changes and incidents start from a current picture of the application.
