Summary

  • CleverCloud should be read as the directory label for Clever Cloud SAS, a French simplified joint-stock company registered in Nantes, rather than as a generic guarantee that every service outcome is French, sovereign, automated, or operationally safe.
  • The strongest public service evidence is the company's own platform documentation: application deployment, managed databases, object storage, CLI and API management, organisation roles, billing controls, observability, network groups, unique IP service, VPN options, zone migration, and support paths.
  • The most useful risk signal is not the brand claim but the boundary between what Clever Cloud runs, what it brokers through infrastructure partners, what customers must configure, and what incidents have shown about Paris availability zones, deployment operations, and dependency on data center and network providers.
  • Buyers should treat French identity, ISO/HDS language, data center lists, and premium support commitments as review inputs, then test the exact zone, recovery, support, access, data-processing, billing, and network evidence that their own application would depend on.

The first useful thing to say about CleverCloud is that the spelling on a directory card is not the operating company. The public legal record behind the cloud name is Clever Cloud SAS. Its own legal notice identifies the company as a French simplified joint-stock company, registered in the Nantes trade register under RCS Nantes B 524 172 699, with headquarters at 4 rue Voltaire in Nantes and VAT number FR 87 524 172 699. That is a stronger starting point than a slogan because it gives a buyer a legal person, a jurisdiction, a corporate address, and a support contact surface.

It does not, by itself, prove resilience, data residency, network control, or customer-specific recovery. It gives the investigation somewhere to stand.

That distinction matters because cloud marketing often compresses three separate questions into one word. One question is identity: who is the contracting and accountable company? Another is service scope: which technical functions are delivered by the platform and which are left to the customer or to third-party infrastructure? A third is operating evidence: what does the public record show when there is a deployment problem, an availability-zone incident, a support escalation, a data-location requirement, or a network allowlist request?

Clever Cloud has public material for all three, but the material is uneven in the way most operating records are uneven. The company has a clear French corporate identity and a substantial product surface. It also relies on named data center and cloud infrastructure locations, and its incident material shows that the operating surface is not sealed away from provider power, fiber, control-plane, or hypervisor events.

The company describes itself as a European Platform as a Service provider that helps development teams put applications and services into production with automatic scalability and transparent pricing. On its public site it presents the platform as a way to run, automate, observe, secure, and manage IT environments. The product language includes application runtimes, managed databases, object storage, infrastructure automation, logs, metrics, alerts, identity and access management, and several managed services. For a developer or platform team, this is the practical center of the company.

Clever Cloud is not just selling rack space under a French company name. It is selling a managed layer that turns application deployment, database provisioning, scaling, monitoring, billing, and support into a recurring operating relationship.

The operating promise is attractive precisely because it removes repetitive work from teams that would otherwise own more servers, packages, database maintenance, backups, access controls, and deployment glue. The documentation describes deploying applications through Git, the Clever Tools command line interface, API access, CI/CD integrations, and a web console. It lists runtimes for languages and frameworks, add-ons for databases and services, and administrative pages for domains, scaling, logs, networking, service dependencies, SSH access, billing, and organisation management.

That is enterprise software automation in the ordinary, high-value sense: fewer manual deployment steps, more standardised controls, and more work moved into a platform that can be repeated across teams.

Yet automation is not the same as absence of labour. It changes where labour sits. A team using Clever Cloud still has to decide which zone to use, which add-ons to provision, which organisation roles to grant, how to configure deployment hooks, what to monitor, how to handle secret rotation, how to separate billing by organisation, how to manage incident communications, and how to test recovery. The vendor's work is to make those actions simpler and more consistent. The customer's work is to ensure that the configuration matches the risk of the application.

The record supports a view of Clever Cloud as a service that can reduce operational friction, but not a view that friction disappears.

The strongest product proof is in the breadth of practical documentation. Clever Tools is described as a command line interface for creating and managing applications, databases, storage add-ons, and authenticated API access. The quickstart material points teams toward deployment through Git and explains that deployment removes the Git folder on the server side for security reasons. The add-on list includes managed PostgreSQL, MySQL, MongoDB, Redis, Elastic Stack, Pulsar, Keycloak, Matomo, Metabase, Jenkins, object storage, file-system buckets, and other services.

The DBaaS page describes ordering managed databases from the platform and refers to support for customisations such as leader/follower replication, extensions, and bespoke configurations. Those records do not prove every workload will be faster, cheaper, or safer on Clever Cloud. They do prove a real product boundary beyond a directory entry.

For customers, the product boundary is also a question of what can be inspected. A self-managed stack gives a team direct control over every machine but also hands it every upgrade, patch, incident, and capacity problem. A managed PaaS hides much of that detail in exchange for repeatability and support. The right diligence question is therefore not whether Clever Cloud automates deployment. The documentation shows that it does. The question is whether the buyer can inspect enough of that automation to trust it for the workload in question.

That means looking at logs, metrics, deployment records, backup and restore procedures, database version policies, status history, organisation roles, API tokens, billing details, and support response commitments.

The data-sovereignty claim needs the same care. Clever Cloud says it is a French company operating within the European Union and presents commitments around GDPR compliance, ISO 27001, HDS, reversibility, and protection from certain extraterritorial legal risks. Its home page says it operates its own data centers in France and makes a strong sovereignty case. Its infrastructure page lists French sites in or around Paris and northern France, including Nanterre, Paris, Aubervilliers, Saint-Ouen-l'Aumone, Roubaix, Gravelines, and a Cloud Temple option in France for SecNumCloud needs.

Those facts are significant for French and European customers, especially public sector, health, regulated software, and companies trying to reduce exposure to non-European cloud control.

But the same infrastructure page also lists non-French or partner locations, including London, Quebec, Singapore, Sydney, and Dubai, alongside French sites. The zone migration documentation uses Paris to Montreal as an example of moving services from one zone to another. That does not weaken the French identity claim; it clarifies its boundary. Clever Cloud can be a French provider with French infrastructure options and still operate a multi-zone platform that includes locations outside France. A buyer cannot infer data residency from the company name.

The buyer has to inspect the selected zone, the applicable service, the add-ons involved, the data-processing agreement, any subprocessor or infrastructure dependency, the support path, and the migration controls.

That distinction is especially important for health, public, or sovereignty-sensitive workloads. The company advertises ISO 27001 and HDS language and describes a SecNumCloud zone available through Cloud Temple on request. Those are not interchangeable badges. ISO 27001 speaks to an information security management system. HDS is relevant to French health-data hosting contexts. SecNumCloud is a high bar for certain French sovereign-cloud use cases, and the public language here points to an available zone on request through a partner, not a universal status applied to every product in every region.

The review should therefore start from the exact service order, not from a general compliance page.

The network and resource evidence is useful because it resists abstraction. Clever Cloud's networking documentation says some external services require allowlisting customer source IPs, while applications may be deployed somewhere inside the chosen zone, making the outgoing IP difficult to predict without a dedicated arrangement. The company describes a unique IP service per region that support can configure to give traffic a fixed source IP, with a documented monthly price at the time the documentation was written.

It also describes VPN service options, including WireGuard, IPSec, and OpenVPN, for customers or providers that need encrypted links between Clever Cloud regions and another data center. This is not flashy evidence, but it is operationally valuable evidence: real customers need fixed egress, VPNs, and allowlists, and the vendor has to say how those cases work.

Network Groups extend that evidence. The documentation describes Network Groups as a way to create private, encrypted communication between resources inside Clever Cloud infrastructure using WireGuard, with the possibility of connecting external resources. The model has network groups, members, and peers. It can link applications and add-ons so they can communicate over a private network. The command line documentation shows Network Groups being created, listed, linked, unlinked, and targeted to organisations. That tells a buyer that the platform is not limited to public endpoints and basic app deployment.

It has a network isolation feature aimed at distributed architectures, sensitive environments, and mixed internal/external service designs.

There is a boundary here too. Network Groups are a product control, not proof that Clever Cloud owns or announces a particular autonomous system, not proof of BGP resilience, and not proof that a customer's architecture is private by default. The broad public record available for this review did not establish an authoritative Clever Cloud ASN or routing policy that should be used as service assurance. The safer interpretation is narrower: the company publishes practical IP, unique egress, VPN, private network, and zone documentation. Those records help a buyer design service connectivity.

They do not replace independent network diligence for regulated, high-availability, or peering-sensitive systems.

Status and incident records are where the marketing promise meets the platform as operated. Clever Cloud's public status page recorded no incident for July 14, 2026, but it also showed a degraded deployment-performance incident on July 13, 2026. During that incident, deployments were affected and some restarting applications could temporarily become out of sync and return 503 errors while affected components were being restarted.

The same status page recorded a July 10, 2026 loss of a network link between two Paris availability zones, with the company saying its infrastructure had enough redundancy to absorb the loss and that no service disruption had been observed. Later updates attributed the link problem to a provider manual intervention on fiber infrastructure and said systems were operating normally after the link stabilised.

Those are constructive details because they show two different kinds of operational record. One was a deployment-plane problem with visible errors for certain redeployed applications. The other was a network-link problem where redundancy appears to have absorbed the event. Neither should be exaggerated. A single status entry does not prove a general deployment weakness. A single absorbed fiber incident does not prove all network failures will be absorbed.

Together, they show that the platform's trust story has to include availability-zone links, deployment controllers, provider coordination, and customer communications, not only the words "high availability" on a product page.

The March 3, 2025 postmortem is more revealing. Clever Cloud described an electrical power outage at one of its data center providers that disrupted the PAR6 availability zone in the EU-FR-1 region. It said networking traffic was perturbed and the infrastructure experienced I/O and memory pressure, leading to instabilities and downtime. It also said customers relying on the EU-FR-1 Paris region were affected, along with remote zones depending on the EU-FR-1 control plane and some private zones, while on-premise zones were not impacted.

Product impact included application performance degradation, traffic issues, blocked deployments, failed upscaling and downscaling operations, and possible degradation or unavailability for databases on affected hypervisors, while the record states data loss did not occur for those database categories.

That postmortem is an important control point for this company. It shows that the service has a real status and post-incident explanation culture, which is better than silence. It also shows the operational shape of a PaaS failure: an infrastructure event can move through power, network traffic, hypervisor pressure, deployment API reachability, runtime traffic, database performance, and customer recovery actions. For buyers, the postmortem should lead to questions about region architecture, control-plane dependency, private-zone independence, backup tests, failover expectations, and support escalation.

The lesson is not that Clever Cloud is unreliable. The lesson is that the platform is concrete enough to fail in concrete ways, and those ways should be reviewed before a customer relies on the brand for a critical workload.

Support is one of the places where Clever Cloud's French identity becomes more than jurisdiction. The legal notice gives technical support at [email protected] and lists support hours from Monday to Friday, 9 a.m. to 6 p.m. CET/CEST. The support documentation says basic support is free to all users, including non-paying users, and that email support should respond within a few hours, or within two business days in the worst case. It also describes a console ticket center where customers can start a conversation with engineers, creating threads for individual issues, and notes that organisation members can be added to ticket discussions by email.

That support model matters because managed cloud services replace some in-house labour with vendor labour. A customer does not merely buy automation; it buys a queue, a set of engineers, a support process, and a level of confidence that questions will be answered by people who can see the platform. Clever Cloud's public support language is fairly specific for ordinary support, and the presence of a named Chief of Support Experience on the public executive page reinforces that support is part of the company's operating story. But standard support hours are not the same as critical support.

Customers that need around-the-clock commitments have to look at the Premium offer and policy.

The Premium record is specific enough to anchor a commercial review. Clever Cloud Premium advertises 99.99 percent annual availability for eligible services, a 24/7 on-call hotline, priority handling, contractual intervention and resolution times, and more personalised follow-up. The public page says critical or major incidents receive a guaranteed time to intervention of fifteen minutes through the dedicated line and a guaranteed time to resolution of two hours, while minor incidents have business-hours targets. The premium page also states a pricing formula of 1.8 times monthly consumption plus EUR 490 before tax per month.

The premium policy ties the 99.99 percent guarantee to services for which the customer has subscribed to the option.

That is not a casual add-on. It changes the cost and risk model. A small team using standard support may rationally accept business-hours support if the workload is low risk or has alternative controls. A regulated or revenue-critical customer must decide whether the premium cost is justified by the hotline, response times, service credits or penalties, and operating attention. The key is to compare the premium commitment with the customer's own cost of downtime, engineer availability, failover architecture, and contractual obligations to its users.

Premium support is evidence of a service boundary; it is not a substitute for resilience design.

Access governance is another practical layer. Clever Cloud's organisation documentation describes separating personal space from organisations, adding collaborators, and assigning roles. It lists roles such as Admin, Manager, Developer, and Accountant with different rights, including adding members, adding applications, removing applications, managing add-ons, editing or deleting organisations, accessing bills, and accessing repositories. The billing documentation describes monthly invoices by organisation and detailed service consumption. Notifications documentation explains deployment-result emails and webhooks.

These are ordinary controls, but ordinary controls decide whether a platform is usable in a company rather than only by an individual developer.

For an enterprise buyer, organisation roles and billing records help answer a deceptively simple question: can the company run this platform without losing track of who changed what, who pays, who receives incident or deployment messages, and who can remove critical resources? Clever Cloud's public material provides building blocks. It does not show the customer's actual configuration. A buyer should test role separation, token creation and revocation, deployment permissions, billing visibility, default notifications, and whether support discussions reach the right people during an incident.

Automation that bypasses accountability creates new risk; automation tied to clear roles can reduce it.

The managed database surface deserves special attention because PaaS convenience often hides stateful risk. Clever Cloud markets managed databases such as PostgreSQL, MySQL, MongoDB, Redis, Elastic Stack, and its own Materia services. Its documentation has repeated product updates around PostgreSQL, MySQL, Redis, Keycloak, Metabase, Otoroshi, and other add-ons. This shows an active platform, but stateful services cannot be assessed by product names alone.

Database review should look at version policy, maintenance notices, backup and restore paths, replication options, zone placement, support scope, extension availability, data-processing terms, and incident history. The March 2025 postmortem is useful here because it separates data loss from degradation and availability. The record says data loss did not occur for the listed database categories during that event, but it also says customers on affected hypervisors could have seen degradation or unavailability.

That is the right level of specificity for a buyer's checklist. If the application cannot tolerate database unavailability, the customer needs a design stronger than a managed database checkbox. If it can tolerate short outages but not data loss, the customer needs backup, restore, and incident evidence. If it uses health data, public-sector data, or sensitive customer data, the customer needs the exact HDS, ISO, DPA, location, and support boundary. Clever Cloud's material gives starting evidence for those conversations. It should not be stretched into a blanket guarantee.

Interoperability and reversibility are also part of the sovereignty story. Clever Cloud says interoperability and sovereignty are compatible and presents commitments around European operation, GDPR, ISO 27001, HDS, and clear contractual and technical reversibility. Its public site points to Git, GitLab, Terraform, API access, and CLI tooling. The reversal risk in a managed platform is not only whether an application can be moved out in theory. It is whether data, build procedures, environment variables, domains, storage, databases, logs, and dependencies can be reconstructed under time pressure.

The platform's standard tools help, but a customer has to maintain its own exit evidence: infrastructure definitions, database dumps or replication strategy, object storage migration plan, domain control, secret inventory, and a tested runbook.

That word "sovereignty" can otherwise do too much work. In one usage it means the vendor is French and governed in France. In another it means workloads can run in French data centers. In another it means a regulated French or European customer can satisfy a specific legal or security framework. In another it means a customer has enough practical control to leave, recover, or prevent lock-in. Clever Cloud has evidence in each area, but the evidence is not identical.

A procurement decision should map each requirement to a concrete control: corporate identity to legal notice and contract, location to selected zone, compliance to certificate scope and service order, reversibility to tooling and tests, support to standard or premium terms, and resilience to architecture and incident evidence.

The public customer references on Clever Cloud's site are worth reading as marketing testimonials, not as system proof. They speak to productivity, scalability, data protection, and confidence from named customers or teams. They can be useful for understanding market positioning and buyer personas, especially French software publishers, public sector bodies, healthcare organisations, and technology teams that want a local provider. But references are not benchmarks. They do not establish precision, uptime, mean time to recovery, false positives, or migration cost for another customer.

The more reliable method is to use testimonials to shape questions, then ask the vendor for service-level, incident, architecture, and support evidence for the actual workload.

The commercial question is therefore not "is Clever Cloud a cloud provider?" The public record supports that it is. The question is whether a subscription reduces real operating risk after the customer accounts for migration work, developer retraining, platform limits, premium support cost, add-on pricing, egress or unique IP needs, compliance review, and the new dependency on Clever Cloud's support and control plane. For a team currently struggling with unmanaged servers, inconsistent deployment habits, weak monitoring, and ad hoc database maintenance, the platform could reduce risk by standardising the work.

For a team with highly specialised networking, unusual stateful systems, or strict cross-region independence requirements, the platform may still help, but only after deeper testing.

A buyer should start with identity and contract review. Confirm that the counterparty is Clever Cloud SAS, that the contract matches the selected product, that the DPA covers the processing role, that the selected zone satisfies data-location requirements, and that any premium support terms are actually included. Then move to technical proof. Deploy a representative application, provision the required add-ons, configure logs, metrics, alerts, access roles, deployment hooks, backup and restore, fixed egress or VPN if needed, and a Network Group if private communication is part of the design.

Test not only the happy path but a failed deployment, a support ticket, a database restore, a role change, an invoice review, a status-page subscription, and a migration between zones or away from the platform.

The same buyer should ask what the platform does not show publicly. Are there detailed subprocessor lists for the exact service? Which products are covered by each certificate or regulated hosting claim? What is the control-plane dependency for a private or remote zone? What is the recovery objective for the selected database plan? How are customer notifications routed during a deployment incident? What logs are retained and for how long? How are API tokens rotated and revoked? How quickly can unique IP or VPN service be provisioned? What happens when an infrastructure provider reports a fiber or power incident?

These questions are not hostile. They are the normal cost of turning a public cloud name into an operating decision.

One reason those questions matter is that Clever Cloud's service surface sits between developer convenience and infrastructure accountability. A developer may experience the platform as a clean deployment target: connect a repository, set variables, choose a runtime, attach a database, watch logs, and let the platform do the rest. An operations leader sees a different picture. The same service becomes a chain of identity records, deployment credentials, organisation roles, support queues, status notifications, data-location choices, storage policies, backup tests, and incident histories.

The value of a PaaS is that those layers are assembled more quickly. The risk is that the assembly can look simpler than the dependency chain underneath it.

This is why the evidence should be read in layers rather than as a single score. The legal layer is strong enough for basic identification: there is a named French company, address, trade-register number, VAT number, and support contact. The product layer is strong enough to show a real managed platform with application runtimes, add-ons, CLI/API controls, private networking features, billing, roles, and support channels. The infrastructure layer is mixed by design: there are many French locations and also partner or non-French regions.

The incident layer is useful but limited: public status and postmortem records show both transparency and concrete failure paths. A buyer that keeps those layers separate will make fewer category errors.

The data-processing agreement belongs in that layered reading. It treats Clever Cloud as a processor acting on the customer's instructions for personal data, using European standard contractual clauses and obligations around purpose, instruction, and security. That is meaningful for a customer that has to document GDPR roles. It also leaves work for the customer.

The customer remains responsible for knowing which data is processed, which third parties or zones are involved, whether the selected service is in the intended region, whether the controller's own instructions are lawful, and whether the architecture matches the promised controls. The contract surface supports diligence; it does not perform diligence by itself.

The same is true of reversibility. Clever Cloud's public language stresses contractual and technical reversibility, and the tooling record gives customers several useful handles: Git deployment, CLI commands, API access, Terraform references, database documentation, storage services, and zone migration guidance. But reversibility is only real when the customer has rehearsed it.

A customer that never exports its database, never records its environment variables outside the console, never tests domain cutover, never documents add-on dependencies, and never validates backup restore may discover too late that the theoretical exit is slower than the business can tolerate. The vendor can provide tools; the customer has to preserve the exit trail.

That trail is especially relevant for teams choosing Clever Cloud because they want a European alternative to larger global providers. Sovereignty projects often start with a legal or political preference, but they succeed or fail on operational detail. If an application is placed in a French zone, attached to a managed database, protected by a Network Group, billed to the right organisation, watched through logs and metrics, and supported by a documented escalation path, the French provider choice becomes a working control.

If the same application quietly depends on an untested external API, an unrecorded token, a hard-coded allowlist, and a support plan that does not match the incident severity, the sovereignty label will not save the service.

For smaller teams, Clever Cloud's appeal may be different. The relevant comparison may not be a hyperscale enterprise contract. It may be a small engineering group currently maintaining servers, packages, databases, deployments, and monitoring by habit. For that buyer, the platform's automation can replace a fragile set of manual routines with repeatable deployment, managed add-ons, billing by organisation, and visible support. The risk is cost surprise, platform limits, and dependence on a vendor queue.

The review should therefore be practical: deploy a real service, create and restore a database, use the CLI, open a support ticket, review an invoice, and decide whether the gained consistency is worth the recurring spend.

For larger organisations, the review shifts toward control mapping. The platform may fit a team or workload, but procurement, security, finance, data protection, and operations will each ask different questions. Security will want identity, access, logging, token rotation, network segmentation, vulnerability response, and certificate scope. Finance will want organisation-level billing, invoice detail, and premium price impact. Data protection will want processing role, region, retention, and transfers. Operations will want incident notification, support escalation, recovery objectives, status history, and migration plans.

The public record gives starting material for each group, but the groups should not substitute one another's answers.

Clever Cloud's July 2026 status records also show why deployment operations should be tested separately from runtime availability. A platform can serve live applications while deployment operations are degraded, and that still matters. If a customer relies on frequent releases, autoscaling changes, emergency fixes, or rapid rollback, a deployment-plane incident can become a business incident even when existing traffic is mostly stable. Conversely, a network-link problem between availability zones may be absorbed by redundancy and still deserve review because it reveals provider dependency and control-plane coordination.

Availability is not one measurement. It is the interaction of runtime traffic, deployment control, database state, network paths, and support communications.

The March 2025 postmortem reinforces that point by separating several forms of impact. Applications saw traffic and performance problems. Deployment operations were blocked by API reachability. Databases could be degraded or unavailable on affected hypervisors. Control-plane dependencies connected Paris to remote or private zones. On-premise zones were described as unaffected. A buyer should not collapse those distinctions. They help determine which architecture is safer: a standard public zone, a private zone, an on-premise arrangement, a premium support plan, a multi-zone design, or a workload left elsewhere.

The postmortem is valuable because it gives enough shape to ask those architecture questions.

There is also a cultural signal in the documentation itself. Clever Cloud publishes many operational pages that are not pure sales copy: networking and IP constraints, support timing, organisation roles, billing details, zone migration, Network Group commands, and postmortems. Those pages make the company easier to evaluate because they expose small frictions and caveats. A thin provider hides those details until after purchase. A more assessable provider lets buyers find the ordinary edges before they sign. That does not mean every edge is solved. It means the review can move from vague trust to specific tests.

The final assessment should therefore be written as a decision record, not a verdict. "French PaaS with credible public documentation and support surface" is a defensible statement. "Sovereign enough for every French workload" is not. "Useful automation for application deployment and managed add-ons" is defensible. "No operational labour left for the customer" is not. "Network controls include fixed egress, VPN options, and private Network Groups" is defensible. "The public record proves full network ownership or routing resilience" is not.

This vocabulary discipline matters because cloud procurement is full of attractive nouns. The operating decision has to live in verbs: deploy, restore, migrate, revoke, notify, escalate, fail over, and leave.

That decision record should include a dated evidence review, because cloud services change quickly. Clever Cloud's documentation shows a living product surface with changing runtimes, add-on versions, console features, network features, and security updates. That is a positive sign for a platform provider, but it also means a review cannot be frozen forever. A customer that approved a workload last year should still revisit the selected region, database version, premium coverage, support contacts, token inventory, alert routing, and migration path before renewing a critical dependency.

If the workload has grown, added regulated data, changed release frequency, or become more revenue-sensitive, the original review may no longer match the exposure. The useful question is not whether the company once had the right public materials. It is whether the customer's current service order and current operational evidence still match the risk the customer is carrying.

For all of the caution, the record is stronger than a thin company card. Clever Cloud has a traceable French legal identity, a documented PaaS product, managed database and storage services, public infrastructure locations, public support terms, premium support commitments, status history, postmortem culture, and network-adjacent controls. The evidence supports a company that can be assessed as an operating platform. It does not support treating every claim about sovereignty, automation, reliability, or support as automatically satisfied for every customer and every region.

The best reading of CleverCloud is therefore neither promotional nor dismissive. It is a French cloud-service actor whose value lies in making application operations more repeatable while keeping a local legal and support story close to the buyer. Its risk lies in the same place as any managed platform: shared control, service-specific contracts, partner infrastructure, control-plane dependencies, configuration choices, and incident response. The buyer's job is to keep those layers separate. The brand can open the file. The record has to close it.