Managed Site Operations

Onboarding begins with an authorised service register. It records every production site in scope, its purpose, business owner, technical owner, source repository, hosting provider, DNS and certificate control, deployment route, content system, database, forms, email path, analytics, consent tooling, third-party scripts and critical integrations. Staging, preview, disaster-recovery and legacy environments are named separately. Unknowns remain marked as unknown; a login discovered during handover is not evidence that ownership or recovery rights are settled.

We then map the journeys that matter to the business. A brochure site may depend on page delivery, enquiry forms and consent records; an ecommerce surface adds catalogue, basket, payment, transactional mail and fulfilment hand-offs; a multilingual corporate estate may depend on locale routing, canonical and hreflang integrity, publishing workflows and regional forms. The operating plan gives each journey an owner, an observable signal and an escalation path. Monitoring the home page alone cannot represent all of them.

The proposal states when the service is staffed, which channels open a case, who may authorise a release or emergency action and how severity is assigned. A response target means the case is acknowledged and triaged within the agreed window; it is not a promise that every fault will be fully resolved by that time. Provider outages, expired client contracts, unavailable source code, missing licences and decisions waiting on a client owner can all affect restoration. These dependencies are visible before the first incident.

Access is reduced to the work required. Named accounts, multifactor authentication, role separation, recovery contacts and an access register replace shared passwords wherever the platform permits it. Privileged credentials are transferred through an approved secure channel and revoked when no longer needed. The client retains ownership of domains, accounts, repositories, data and licences unless a written agreement says otherwise. NobleJackal’s role is operator within the commissioned boundary, not silent owner of the client’s estate.

Monitoring is designed from the service journeys and failure modes. Depending on scope, it may include external availability, DNS and TLS validity, expected page content, form or transaction checks, server and application health, error rates, queue or job failures, resource pressure, backup status, search visibility safeguards and selected performance indicators. We also monitor the monitoring path where practical. A green dashboard built from a broken probe is worse than no signal because it creates false confidence.

Signals are classified as immediate action, scheduled work or evidence for later diagnosis. Thresholds account for duration, traffic, geography, maintenance windows and known dependencies so one transient request does not wake a person without reason. Alerts name the affected service, observed condition, time, evidence and first safe checks. Email inboxes are not treated as an on-call system unless the written service explicitly makes them one. Noise, stale alarms and blind spots are reviewed rather than allowed to become normal.

An incident has roles. The operator establishes impact and severity, protects evidence, records a timeline, communicates through the agreed channel and works within pre-authorised actions. Changes that could affect data, security, legal duties, customer communication or commercial transactions go to the named client authority. If a hosting, DNS, SaaS, payment, email or other supplier is responsible, NobleJackal can coordinate the case within scope, but the supplier controls its platform and its own response times.

Recovery is followed by verification, not a quick declaration that the page loads. The affected journeys, data integrity, forms, integrations, certificates, cache, search directives and representative devices are checked as relevant. Material incidents produce a concise record of impact, contributing causes, actions, evidence and follow-up ownership. The purpose is to reduce recurrence and improve the runbook, not to manufacture certainty about a complex system or assign blame without evidence.

The current production state is tied to a repository, build or documented source package wherever the stack permits it. Dependencies, runtime versions, configuration, secrets, database changes and generated assets are recorded at the level required to reproduce a release. Direct edits on the live server are treated as controlled exceptions because they are difficult to review, test and reverse. Where inherited systems lack a reliable source of truth, stabilisation is quoted before routine release work begins.

Updates are grouped by risk. A text correction, a CMS extension update, a runtime upgrade, a database migration and a change to checkout do not follow the same route. The release plan states required review, automated and manual tests, staging or preview use, backup or snapshot, maintenance window, cache and CDN actions, monitoring period and rollback trigger. Security patches may require an accelerated path, but urgency does not remove the need to record what changed and who authorised it.

A release is accepted against the actual package deployed, not a developer’s local folder. We preserve a manifest, version or commit reference and verify the public result after deployment. Checks may include status, content markers, forms, authentication, integrations, canonical and robots directives, analytics consent, error logs and representative responsive views. Progressive rollout or a canary is used where the architecture supports it and the risk justifies it. A successful upload is never treated as proof that the service works.

Rollback is prepared before the change. Code, configuration and data do not always reverse in the same way; an incompatible database migration may make an old application build unsafe. The runbook therefore defines the recoverable unit, dependency order, decision owner and stop conditions. If rollback is not technically credible, the change carries a different risk class and may require a new environment, vendor support or a dedicated engineering commission outside monthly operating capacity.

Performance work starts with the page and audience affected. Field Core Web Vitals, real-user data, synthetic tests, server timing and application traces answer different questions and may not all be available. We segment by template, device, geography and release where the evidence permits it. A lab score from one workstation is useful for diagnosis but does not prove the experience of real users. Budgets for images, scripts, fonts, API calls and third-party tags make regressions easier to detect during change review.

Security maintenance covers the items expressly listed in the proposal: for example CMS core, themes, extensions, application dependencies, runtime, server packages, certificates or configuration. Advisories are triaged for relevance and exposure before action. Unsupported components, abandoned plug-ins and bespoke code may require replacement or engineering rather than a routine update. Managed Site Operations is not a staffed SOC, penetration test, forensic service, compliance audit or promise that every vulnerability and attack will be detected or prevented.

Backups are described by source, content, frequency, retention, location, encryption, access and restore authority. A successful scheduled job is evidence that a process ran, not that the copy contains everything needed or will restore within a business objective. Representative restoration checks are commissioned and recorded separately from availability monitoring. Application, database, media, configuration, DNS, certificates and third-party data may require different recovery methods and owners.

Hosting and operations remain distinct even when NobleJackal supplies both. Hosting Core is a USD 200 annual add-on for existing NobleJackal clients: France-based Linux hosting, a separate cPanel account, allocated IP address, SSL, CloudLinux isolation, weekly backups, Imunify360, ImunifyAV+, initial migration and routine hosting administration. It does not include continuous monitoring, controlled releases, incident response, performance engineering, operating reports or committed support times. Managed Site Operations begins at USD 500 per month and adds an accountable operating layer under a separate written scope.

The operating record covers the agreed sites and period. It can show availability and journey checks, significant signals, incidents, changes, releases, rollback events, patch decisions, certificate and dependency status, backup evidence, performance movement, supplier cases, capacity use and open risk. Each item retains a date, owner, source and state. A metric is not reported as a service-level result unless its collection method and coverage match the written agreement.

The improvement register separates urgent remediation, planned maintenance, technical debt and optional development. The client can see what fits inside the agreed monthly capacity, what is waiting on an owner and what requires a separate estimate. Content production, redesign, new features, migrations, major upgrades, architecture changes, search programmes and disaster-recovery design are not smuggled into a maintenance label. They move through written change control with their own acceptance criteria.

Managed Site Operations starts at USD 500 per month. The final price depends on the number and criticality of sites, technologies, environments, integrations and suppliers; operating hours; monitoring depth; release frequency; response authority; monthly engineering capacity; reporting; languages; compliance constraints and inherited technical risk. Hosting, cloud consumption, licences, monitoring products, domains, certificates, third-party support and emergency work outside the agreed window are excluded unless the proposal expressly includes them. There is no implied 24/7 desk or unlimited development.

Handover is designed from the start. The client receives the current register, authoritative sources, access inventory, monitoring and alert rules, release and rollback path, incident and supplier routes, backup and recovery evidence, open actions, residual risks, reports and known limitations in the agreed form. Access is transferred or revoked under named authority. Managed operation can improve control and response, but it cannot guarantee uninterrupted availability, a fixed recovery time, perfect security, performance scores, search ranking, AI citation, leads, sales or revenue.