The service no longer responds.
Server errors, an unavailable journey, authentication problems or failed transactions. We start by identifying what is genuinely affected.
An unavailable service, a blocked release, a degraded database or an attack under way: one technical contact to organise the response and contain the impact.
Availability and response time are confirmed after qualification.
Affected services · users · timeline
People · access · authorised actions
Remediation · business journeys · monitoring
Report · causes · lasting actions
The form structures the affected service, the impact, the timeline and how to call you back. For an attack, describe only the symptoms observed and the systems involved.
Direct line: +33 7 67 46 80 46Server errors, an unavailable journey, authentication problems or failed transactions. We start by identifying what is genuinely affected.
Regression, incompatibility, configuration or dependency: the latest changes help direct the investigation and study a restoration.
Resource saturation, slowness, database errors or breaks between services: the intervention accounts for the dependencies and the access available.

We can work on preventive defence and on the response to an attack under way, within the scope of your systems and with explicitly authorised actions.
Collecting and reading logs, monitoring, hardening, isolated backups, access control, detection of indicators of compromise and preparation of procedures.
Isolating hosts, blocking indicators, revoking sessions, preserving useful evidence, controlled eradication and progressive recovery under watch.
Speed must not create a second incident. We organise the exchanges, the authorisations and the tracking of actions during remediation.
Prepare the reportIdentify someone able to confirm the business impact, organise access and approve the actions that change the system.
We line up the symptoms, the recent changes and the first actions. Hypotheses stay separate from observed facts.
Operations are prioritised by impact and by the ability to roll back. Concurrent changes are avoided as far as possible.
An HTTP response is not enough: the affected journeys must be checked with your people before declaring the service restored.
The review separates the immediate fix from the lasting changes: observability, capacity, tests, deployment procedure or backups.
If the context calls for it, we then frame an audit, maintenance or on-call support. That continuation remains a scope of its own, distinct from the emergency.
Maintenance & continuity ↗| Information | How to phrase it |
|---|---|
| Impact | The ordering journey fails for every user. |
| Start | The incident has been observed since this time, in this time zone. |
| Changes | A version or a configuration was changed before the incident. |
| Contact | Here is the technical contact and the person who can authorise actions. |
Never send a secret through a public form. Access is organised through a suitable channel. A suspected compromise requires an explicitly qualified scope and skill set.
A one-off intervention can be considered once the system, the incident and the required access have been qualified. Scope and conditions are agreed before we start.
The start time, the affected services, the latest changes and a technical contact. Never send a password or any secret through the form.
We propose a review, durable fixes and, if needed, ongoing maintenance or support for your infrastructure.
Distribution SME / business application
Illustrative scenario, not attributed to a real client.
Sales teams can no longer validate orders. A new version was deployed shortly before the first reports; the cause is still to be established.
Qualify the affected journeys, line up the timeline of changes, work through the restoration with the team and verify orders end to end.
A restored and checked service, a timeline of the intervention, the actions taken and a plan to address the established causes.
Let’s start with its impact and the technical context.