Summary
- Vertix’s public materials make the five-minute monitoring interval unusually useful as a procurement test. Detection is only the first clock: a buyer also needs to measure when an authorised engineer takes ownership, when the service is restored, and when contractual evidence arrives.
- Authoritative Brazilian internet-registry entries support Vertix’s control of AS275716 and the IPv6 allocation
2804:987c::/32. Public routing observations show a recent, IPv6-led network presence, but they do not establish workload availability, facility resilience or recovery performance. - The company’s catalogue spans cloud, data-centre services, hosting, telephony, SD-WAN and monitoring. That breadth could reduce vendor-coordination work, yet it also makes product-specific responsibility, support coverage, address ownership, data location and exit rights essential.
- Public pages provide enough pricing and service detail to design serious tests, but this research did not locate a named production-facility map, independent SLA history, public incident archive, customer case study, certificate scope or completed restore evidence. Buyers should request those artefacts without treating their public absence as proof that the underlying controls do not exist.
At 02:13, one red signal starts four clocks
Imagine a procurement drill rather than a real outage. At 02:13 on a Wednesday, a synthetic transaction fails. The monitoring system waits for its next scheduled check, confirms the problem and paints a service red. No actual Vertix incident is being described here; the scene is a controlled test built from a public feature in Vertix’s offer. Its monitoring page advertises five-minute checks on both the Standard and Flex plans, while the custom tier can use a negotiated frequency.
The first clock measures detection. When did the customer-visible symptom begin, when did the probe run, and when did an alert leave the monitoring system? A five-minute interval sets only an upper bound on the scheduled observation gap. Retries, correlation rules, notification queues and a monitor that shares the failed system’s dependency can all lengthen or distort it.
The second clock measures ownership. When did a human acknowledge the alert, and when did someone with authority to change production accept responsibility? An email receipt, a ticket status change and an engineer entering the affected environment are different operational moments. Vertix’s public plans make that distinction material: Standard lists email support, Flex lists 24/5 support, and the custom offer describes VIP 24/7 support and a customised service-level agreement.
The third clock measures restoration. When did the customer’s transaction work again—not merely the host respond to ping, the dashboard turn green or a process restart? Restoration may require a failover, a data recovery, a routing change, a rollback, a vendor escalation or a business decision by the customer. Each path has different authority and dependency requirements.
The fourth clock measures accountable evidence. When did the provider deliver a timeline, impact statement, measurement against the agreed service level, explanation of exclusions, corrective actions and any applicable credit? This clock is often ignored during sales discussions, yet it determines whether the first three clocks can be governed over months rather than demonstrated once.
That four-clock sequence is a more useful way to evaluate Vertix than asking whether a small provider is “reliable” in the abstract. It turns locality into observable work. It also prevents a common category error: equating a nearby office, an active autonomous system or a broad catalogue with a tested recovery capability. Vertix has public evidence that makes it credible enough to test. The purchasing decision depends on what happens when the test starts.
The identity trail is stronger than a brand name
The first procurement question is prosaic but consequential: which legal and operational party will hold the dependency? Vertix’s company site identifies an address on Rua Brasil in Dois Irmãos, Rio Grande do Sul, and uses company-domain telephone and email contacts. Its LinkedIn page points to the same website and municipality and describes a privately held business founded in 2023 with 2–10 employees. Those LinkedIn attributes are self-reported, not audited facts, but the match helps distinguish this business from unrelated uses of the Vertix name.
The more probative identity evidence comes from Brazil’s internet registry. The Registro.br RDAP entry for AS275716 names Vertix Tecnologia Soluções em Cloud, associates the resource with CNPJ 50.391.687/0001-01, and records the autonomous-system assignment on 27 March 2026. The RDAP entry for 2804:987c::/32 assigns the IPv6 block to the same named organisation, CNPJ and ASN. These are authoritative records for internet number resources. They establish a concrete link between the trading identity and an operating surface on the public internet.
They do not settle every corporate question. Third-party business-information sites, including CNPJ.biz, have preserved the name S&S Treinamento e Consultoria Ltda in association with the same CNPJ. Such aggregators can lag, simplify or reproduce historical registration data, so they should not override an authoritative contract or current official company documentation. They do create a precise diligence task: the proposal, invoice, data-processing terms, resource registrant and party accepting service liability should be reconciled to the same CNPJ, with any trade-name or legal-name relationship stated explicitly.
That exercise is not paperwork for its own sake. A service may be marketed by one brand, contracted through another legal name, hosted by a facility operator, routed through an upstream network and supported by a channel partner. When a buyer needs a credit, an emergency change, an evidence package for a regulator or assistance during exit, ambiguity about which party owes the work becomes operational delay. Vertix’s registry trail gives the buyer a solid anchor. The contract must connect every other delivery party to it.
The operating perimeter is wider than “cloud”
Vertix does not present itself as a narrowly defined virtual-machine vendor. Its solutions catalogue groups IaaS, PaaS, SaaS and automation under cloud computing; colocation, dedicated hosting and managed servers under physical data-centre services; and dedicated resources, high availability, management and scaling under a virtual-data-centre offer. It also lists web hosting, corporate email, IP telephony, SD-WAN and infrastructure monitoring.
That breadth matters because a customer does not experience infrastructure as a catalogue. A retail system, manufacturer, professional-services firm or regional internet provider experiences a chain: connectivity reaches an application; identity allows a user in; DNS sends traffic to an address; compute runs code; storage preserves state; backups create a recovery point; telephony carries customer contact; monitoring detects failure; and support coordinates whatever crosses supplier boundaries. A provider that can genuinely own several links may remove substantial coordination work from a small internal IT team.
The same breadth can hide discontinuities. “Managed” may mean patching the operating system in one service, opening upstream tickets in another and only sending alerts in a third. A virtual data centre may use a different platform, facility and support queue from shared hosting. Telephony may depend on carriers and number-portability processes outside the cloud team. Monitoring offered as SaaS may sit outside the environment it watches, while an on-premises deployment may inherit the customer’s own failure domains. Public product names cannot resolve those boundaries.
Before architecture design, a buyer should therefore ask Vertix for a product-by-product responsibility matrix. At minimum, it should identify who owns the hypervisor or container layer, operating system, database, application, identity configuration, network edge, DNS, backup policy, restore execution, vulnerability remediation, logging, incident command and customer communication. It should also name material third parties. If one Vertix team coordinates them all, that is a potentially valuable service. If the customer must coordinate them, the apparent single-supplier advantage is smaller than the catalogue suggests.
Clock one: detect the failed customer action
Vertix’s monitoring offer is the most detailed public window into how the company thinks about operations. The page says it can watch Windows, Linux and Unix servers; network equipment through SNMP; applications, databases, websites and APIs; and sites from multiple locations. It describes thresholds, severity levels, correlation, escalation, schedules for teams and working hours, dashboards, history, capacity and SLA reports, and notification or integration paths that include email, SMS, mobile channels, webhooks and several collaboration or service-management tools.
Those are first-party product claims, not independently tested capabilities. Even so, they let a buyer pose better questions than “do you monitor it?” The right first-clock test begins with a customer action: login, checkout, invoice generation, API request, call completion or another transaction tied to revenue or service. Google’s site-reliability guidance distinguishes monitoring from the system’s inside from observation of the user-visible behaviour; its discussion of monitoring distributed systems also stresses that pages should be actionable and that symptoms are often more useful than internal causes.
A host CPU check can be green while a certificate has expired, a database is read-only or an upstream dependency rejects requests. Conversely, a high-CPU alarm may not represent user harm. Vertix’s advertised website, API and multi-location checks create a route to symptom-based assurance, but the buyer must see how they are configured. Which DNS resolver does the probe use? Does it validate response content or only status code? Does it authenticate? Are probes outside the production network and outside its upstream providers? Does the alert require one failure, several consecutive failures or agreement between locations?
What happens when the monitoring platform itself is unreachable?
The five-minute interval also needs a risk classification. A probe scheduled at 02:10 may succeed seconds before a failure at 02:10:05 and not run again until 02:15. Confirmation retries and notification processing can add time. That cadence may be sensible for a brochure site, routine capacity monitor or low-criticality device; it may be too slow for payment, authentication or voice services. The custom plan’s claimed adjustable frequency is therefore not merely an upsell feature. It is a mechanism for aligning detection with a business recovery objective.
The procurement demonstration should inject several kinds of failure into a non-production or safely isolated environment: block an application dependency while leaving the host alive; return an incorrect business response with HTTP 200; break one network path; expire a test certificate; and stop an installed monitoring collector while leaving remote checks available. For each, record the true failure time, first failed probe, alert creation, notification receipt and ticket creation.
The first clock is proven only when the monitoring path catches the failure that matters, at the promised cadence, without sharing the same single point of failure.
Clock two: find the person allowed to act
Detection does not restore a service. The decisive transition is from “the system noticed” to “a named person owns the incident and has authority to change something.” Vertix’s public support language varies by page and tier. Its home page makes a general 24/7 support claim. The monitoring page lists email support for Standard, 24/5 for Flex and VIP 24/7 for the custom tier. Its hosting page advertises support through chat, ticket and telephone, says critical issues receive immediate attention, and states an average ticket response of 30 minutes.
All of those statements should remain attributed to Vertix. “Average” does not reveal the slow tail, the sample period, severity mix or whether the clock stops at an automated reply. “Immediate attention” does not define acknowledgement, investigation or restoration. “24/7” does not show whether the responder is a general service desk, an on-call engineer, a network operator, a database specialist or a third party. The gap between those meanings is exactly what the second clock measures.
A buyer should require a severity matrix with at least four timestamps: alert created, human acknowledgement, qualified engineer engaged and incident commander assigned. The matrix should say which channels can declare a critical incident, who may approve emergency changes, what customer authorisation is required, and when Vertix escalates to an upstream, facility, software vendor or carrier. It should distinguish a response target from a repair target and give percentile or maximum commitments rather than an unqualified average.
The public LinkedIn range of 2–10 employees, if current and accurate, would make staffing resilience a reasonable diligence subject, not a reason for dismissal. A small specialist team can be faster and more accountable than a large queue. It can also be exposed to key-person concentration, simultaneous incidents, holidays and the need to support several product disciplines. Buyers should ask for the on-call design, rota coverage, backup roles, escalation depth and succession arrangements without demanding personal employee data.
Vertix’s partnership page invites integrators, resellers and consultants and discusses evaluation, recurring commissions and possible commercial commitments. A channel can extend implementation capacity and give customers a trusted local adviser. It can also create a handoff between the party that designed the environment, the party that invoices it and the party with privileged access. The incident plan should state whether a partner may open priority cases, approve changes or see customer data, and whether the customer can bypass the partner in an emergency.
The practical test is simple. During the sales process, schedule one declared exercise inside normal hours and one at the edge of the contracted coverage window. Trigger the synthetic alarm, open the stated channel and ask the responder to execute a pre-approved harmless change or failover. Record who joins, what identity checks occur, what evidence they request, which system they can access and when a person with production authority accepts the task. Local support becomes assurance when the authority path is short, secure and repeatable.
Clock three: restore the business, not the dashboard
The third clock ends only when the affected business action works and data integrity is acceptable. A host restart can make infrastructure look healthy while a queue remains corrupt. A route change can restore reachability while sessions fail. A backup job can report success while the archive is incomplete, encrypted with an unavailable key or too slow to restore within the business deadline.
Vertix’s hosting page gives buyers several concrete claims to test. It lists daily backups with seven, 15 or 30 days of retention depending on plan; free migration that includes files, databases and configuration; testing before a nameserver change; and hosting infrastructure said to be in Brazil. These are useful service promises, but retention is not a recovery objective. A daily backup can imply nearly 24 hours of data loss in the worst timing case. It says nothing by itself about replication lag, backup isolation, immutability, encryption, restore throughput or application-consistent capture.
AWS’s reliability guidance treats periodic recovery testing as the way to verify that backups meet recovery-time and recovery-point needs. NIST’s contingency-planning guide similarly places testing, exercises and plan maintenance inside continuity work. These are industry benchmarks, not evidence that Vertix follows either framework. They illustrate why a buyer should request a completed restore rather than a screenshot of successful backup jobs.
The restore exercise should begin with an agreed dataset and end with application acceptance. Ask Vertix to recover a deleted database or virtual machine into an isolated environment, provide the timestamp of the newest recoverable transaction, measure transfer and boot time, validate checksums or application records, rotate any exposed credentials and document every manual dependency. Repeat with the primary administrator unavailable. For geographically resilient designs, test the failure of the production location or connectivity path, not just one guest operating system.
The architecture behind the restoration path remains a major public evidence gap. This research did not locate a named map of Vertix production, backup and disaster-recovery facilities; a description of storage replication or failure domains; or a public record of completed recovery exercises. That does not show these controls are missing. It means the buyer must request the topology, legal site operators, physical separation, power and carrier dependencies, backup destination, recovery orchestration and last exercise report under appropriate confidentiality.
Restoration ownership also needs product-specific treatment. On shared hosting, Vertix may control most of the stack. In a virtual data centre, the customer may control guest systems and applications. In colocation, Vertix may provide space, power, connectivity or remote hands while the customer owns hardware and software. In telephony, number carriers and portability processes enter the path. A single RTO printed across those products would conceal more than it clarifies. Each service needs a recovery boundary and an end-to-end customer acceptance test.
Clock four: produce evidence that survives renewal
The fourth clock converts operations into governance. Vertix’s hosting page claims a 99.9% uptime guarantee in contract. That is specific enough to analyse but not broad enough to apply automatically to cloud, monitoring, colocation, SD-WAN or telephony. A 99.9% monthly target allows approximately 43.2 minutes of unavailability in a 30-day month before any exclusions, assuming the entire service and every minute count. Microsoft’s reliability guidance defines the roles of SLIs, SLOs, SLAs, RTO, RPO and repair metrics, showing why the percentage is only the beginning of a useful agreement.
The buyer needs to know the measurement point: the virtual machine, hypervisor, network edge, HTTP transaction, call completion or full application? Scheduled maintenance, denial-of-service attacks, customer configuration, software defects, upstream failures and force majeure may be treated differently. Partial degradation may or may not count. The provider’s own monitoring may be the official source, or a jointly agreed external probe may be allowed. Credits may require the customer to file a claim within a short window and may be capped at a fraction of monthly fees.
None of those possibilities should be assumed about Vertix without the contract. They are the clauses that determine whether a 99.9% statement protects an actual workflow. Procurement should request the current standard agreement and a product schedule before technical selection, then build a worked example: if the customer transaction fails for 70 minutes but the virtual machine remains reachable, does the SLA record an incident? What data proves it? What remedy follows? If an upstream route fails, which party’s exclusion applies? If a restore exceeds the RTO, is that an availability breach, a support breach or neither?
Evidence after an incident should include a shared timeline, affected service and customers, user-visible impact, detection source, response and restoration timestamps, dependencies involved, data-integrity assessment, security or privacy implications, temporary mitigation, root-cause status and corrective actions with owners and dates. Google’s incident-response guidance emphasises clear roles, communication and practiced procedures. Again, this is a benchmark, not a description of Vertix’s current process.
This research did not locate a public Vertix status-history archive or a named post-incident report. A small provider is not obliged to publish every operational detail, and lack of a public archive is not evidence of a clean or troubled history. It does mean a buyer should request private evidence: 12 months of availability by relevant service, incident counts by severity, support-response distributions, maintenance notices, sample incident reports and closure rates for corrective actions. The fourth clock stops when evidence is delivered in a form the customer can audit, not when the ticket is quietly closed.
The routing footprint is real, recent and narrow in meaning
Vertix’s network presence is more than a marketing assertion. The Registro.br assignments connect the company to AS275716 and its IPv6 block. The PeeringDB entry identifies Vertix Tecnologia, links the corporate domain, lists the route set AS275716:AS-VERTIX, publishes NOC and sales contacts, declares IPv4 and IPv6 support, and records an open peering policy. At the time reviewed, its public exchange and facility tables showed no matching rows. Because PeeringDB is operator-maintained, positive fields are declarations, and blank fields do not prove that private, upstream-mediated or otherwise undocumented interconnections do not exist.
A Hurricane Electric BGP Toolkit snapshot, updated on 15 July 2026, showed two originated IPv6 prefixes, no originated IPv4 prefix, two internet-exchange observations, and direct peer rows naming G2NET’s AS53061 and GGNET’s AS53062. It also listed PTT observations in Caxias do Sul and Porto Alegre. A RIPEstat routing-status view observed the ASN’s route beginning in April 2026 and reported broad visibility for the IPv6 origin in its collector set; the companion announced-prefixes view identified 2804:987c::/32 and 2804:987c:1001::/48 during the observed period.
These data support several bounded conclusions. Vertix has an independently identifiable routing domain. Its public origin history is recent. The observed origin is IPv6-led. At least some paths and exchange-facing addresses are visible to public collectors. None of this measures application latency, packet loss, support quality, server capacity or physical diversity. A route can be globally visible while the application behind it is unhealthy; a cloud can use upstream-supplied addresses that do not originate from the provider’s own ASN.
The IX.br Rio Grande do Sul entity view provides context for a sizeable regional interconnection ecosystem, while IX.br’s CIX participation explanation shows that access can be delivered through a commercial entity rather than only a direct physical port owned by every network. That distinction matters when interpreting exchange evidence. An exchange-facing address does not, by itself, identify the building, port owner, contracted capacity, redundant path or whether customer cloud traffic follows that route.
For procurement, Vertix should provide a current logical and physical network diagram: address families used by each product, origin ASN, upstreams, exchange connections, port ownership, facilities, capacity, routing policy, denial-of-service handling, maintenance process and tested failover. Looking-glass and route-collector data can then corroborate the design. Public routing evidence is valuable precisely because it gives the buyer something external to compare, not because it answers every resilience question.
IPv6 control can coexist with IPv4 dependence
The public evidence suggests a particularly important exit and dependency question. Registro.br assigns Vertix its own IPv6 space, and public collectors see AS275716 originating it. The IPinfo view of AS275716 likewise describes a Brazilian network centred on the ASN and IPv6 allocation. Yet Vertix can still deliver IPv4 through space supplied or originated by another network.
One public example should be handled cautiously. IPinfo’s WHOIS view for 191.241.222.0/24 reproduces registration details for a broader 191.241.222.0/23 block associated with S&S Treinamento e Consultoria Ltda, the same CNPJ and contacts tied to Vertix, while the route is shown under G2NET AS53061. This does not establish that all Vertix hosting, cloud or customer services use that block. It does show why “we have an ASN” is not a complete answer to address portability.
If a customer receives provider-assigned IPv4 addresses originated by an upstream, a move to another provider may require renumbering, DNS changes, firewall updates, allow-list revisions, certificate or application configuration, partner notifications and a period of dual operation. Reverse DNS may require the provider’s action. Long-lived external integrations may have hard-coded source addresses. By contrast, a customer using portable addresses under an appropriate routing arrangement may face different contractual and technical constraints.
The buyer should request an address plan for each proposed service: who is the registry holder, which ASN originates the prefix, whether addresses are dedicated or shared, how inbound and outbound translation works, who controls reverse DNS, whether bring-your-own-IP is possible, and what happens at termination. The plan should cover IPv6 and IPv4 separately. It should also test reachability from networks that do not yet provide equivalent IPv6 paths, because an IPv6-led operator may still rely on an upstream for the IPv4 experience many customers require.
This is not an argument against upstream dependence. Almost every network depends on other networks, facilities and suppliers. The assurance question is whether the dependency is known, diversified where necessary, monitored, contractually supported and compatible with exit. A small provider can manage that chain well. The customer should not discover its shape during a migration away.
One RPKI result is a live test, not a verdict
The Hurricane Electric snapshot showed one originated IPv6 route classified RPKI valid and one classified RPKI invalid, with the more-specific 2804:987c:1001::/48 appearing in the latter category at the time of review. Routing Public Key Infrastructure allows a resource holder to authorise an origin ASN and maximum prefix length. RFC 8481 explains the validation states commonly described as Valid, Invalid and NotFound.
An Invalid state can arise when the observed origin ASN is not authorised by a matching route-origin authorisation or when the announced prefix is more specific than the permitted maximum length. It does not, by itself, prove a hijack, malicious activity, customer outage or enduring configuration problem. Collector and cache views can lag. The route may have changed after the snapshot. It is nonetheless operationally relevant because networks enforcing route-origin validation may reject an invalid route, producing reachability differences across the internet.
The right response is not a sensational incident claim. It is a live procurement test. Ask Vertix to show the current ROAs for its announced prefixes, validate them through more than one independent validator, explain the intended maximum lengths, and demonstrate reachability from networks that reject invalid origins. Ask who monitors route validity, how alerts are escalated, how quickly a mistaken announcement or ROA is corrected, and whether upstreams apply filtering to customer routes.
The test also reveals whether the four clocks extend to the routing layer. When a route becomes invalid, who detects it? Who can change the ROA or announcement? How is service restored across validating networks? What evidence is sent to affected customers? Routing hygiene is not an ornamental network-engineering score. For an internet-facing cloud service, it is part of the customer’s availability path.
Locality has four addresses of its own
“Local cloud” can refer to at least four different addresses: the supplier’s office, the support team, the data and the network attachment. Vertix’s site and LinkedIn presence support a business location in Dois Irmãos. The hosting page claims servers in Brazil. Public routing observations place exchange-facing addresses in Rio Grande do Sul. Those facts are relevant, but they are not interchangeable.
A salesperson or support engineer can be in Rio Grande do Sul while compute runs in another state. Primary data can stay in Brazil while monitoring telemetry, ticket attachments or backup metadata reach a foreign software service. A nominally Brazilian environment can depend on a remote control plane. Conversely, a workload can run in a Brazilian facility operated by a third party while Vertix provides the managed layer. None of these arrangements is inherently unacceptable. Each creates a different risk, latency, jurisdiction and recovery story.
The telephony page adds a useful example of scope ambiguity. Vertix says its data centres have ISO 27001 and describes TLS and SRTP protections for communications. The claim may refer to a facility operator, a platform provider, Vertix itself or a combination. The page reviewed for this article did not identify a certificate number, holder, auditor, validity period, facility or statement of applicability. The buyer should request the certificate and scope rather than either accepting the badge at face value or assuming no certification exists.
Brazil’s General Data Protection Law, the LGPD, distinguishes roles such as controller and operator, requires processing records in relevant circumstances, expects operators to follow controller instructions, and imposes security and incident obligations. The ANPD’s own cloud-computing strategy is an institutional procurement document rather than a universal private-sector contract, but it offers a useful benchmark: cloud terms should make provider roles, access management, compliance and incident handling explicit.
A locality schedule should therefore name production and backup locations, site operators, subprocessors, remote-support locations, telemetry destinations, encryption-key custody, cross-border transfers and disaster-recovery behaviour. It should distinguish “normally stored in Brazil” from “contractually restricted to Brazil,” and describe any exception process. Locality becomes assurance when the four addresses are mapped and bound to duties.
Implementation is where service breadth becomes one workflow
Vertix’s public pages imply several onboarding paths. Hosting advertises free migration of files, databases and configurations, followed by testing before nameserver change. Telephony describes number portability that can take seven to 15 business days. Monitoring offers installed-collector and remote collection, discovery, templates, custom scripts, APIs, database queries, logs and integration with service-management or collaboration tools. The custom monitoring tier mentions assisted deployment.
These claims point to a customer workflow that should be managed as one programme even when products differ. Discovery begins with an inventory of applications, dependencies, data classes, addresses, domains, certificates, telephone numbers, recovery objectives and business blackout periods. Design should identify which components remain with the customer, which move to Vertix, which are supplied by upstreams and how observability crosses those boundaries.
Migration then needs a reversible sequence. Data transfer should be measured and reconciled. Test systems should prove application function, security controls, backups and monitoring before cutover. DNS time-to-live values may need to be lowered in advance. Firewall and partner allow lists must include new addresses. Telephony portability should have a fallback communication path. A cutover should define the point at which the new environment becomes authoritative, the criteria for rollback and the person empowered to make that decision.
Vertix’s broad perimeter could be especially valuable here: one team might coordinate hosting, DNS, monitoring, connectivity and voice rather than forcing a small customer to arbitrate among suppliers. The buyer should ask for a named implementation owner, plan, dependency register and acceptance criteria. If a partner leads implementation, the plan should state who holds the master design and who supports it after the project team leaves.
Operational handover is as important as cutover. The customer needs architecture diagrams, credentials under its control, asset and licence inventories, backup and restore instructions, escalation contacts, maintenance windows, known exceptions and a baseline of performance and cost. Monitoring alerts should map to runbooks and owners. A migration is not complete when traffic moves; it is complete when the recurring four-clock process can be executed by people who were not in the sales meeting.
Public prices illuminate only part of the bill
Vertix publishes unusually concrete entry prices for hosting and telephony. The hosting page lists monthly prices of R$31.90 for Basic, R$44.80 for Flex and R$57.90 for Premium, with lower effective monthly figures for annual payment. The plans differ in storage, transfer allowances, backup retention, support priority, content-delivery features and the Premium tier’s web-application-firewall claim. The page also refers to fair-use treatment around traffic, which means “unlimited” or high-volume language should be read with the applicable policy and upgrade path.
The telephony page lists R$74.95 per month for a Basic plan with a five-user minimum, R$181.41 for Flex with a ten-user minimum and R$345.65 for Premium with a 25-user minimum. It separately describes extension and recording economics and indicates that line charges are not necessarily included in the displayed plan. These figures are valuable because they show the structure of the offer: a base subscription, minimum scale and feature or usage additions.
They do not establish the economics of the broader cloud and managed-infrastructure portfolio. This research did not locate a sufficiently complete, current public schedule for compute, storage, snapshots, backups, public addresses, traffic, licences, managed administration, after-hours projects, security services, colocation power or exit assistance that could be safely treated as the whole commercial model. Those items may be quoted individually. The buyer should request a bill of materials and a model invoice at normal load, expected peak and a failure month involving restores or emergency support.
The comparison unit should be the business service, not a virtual CPU. Include implementation, support tier, monitoring, backup storage, restore labour, traffic, IP addresses, licences, taxes, partner margin, change requests and the internal staff the customer must retain. Annual discounts should be compared with the notice period and exit cost they create. A low hosting price may be appropriate for a simple site but says little about a managed database or a multi-site SD-WAN.
Transparent alternatives create useful pressure. Locaweb Cloud publishes hourly and monthly component pricing and advertises a 99.9% SLA and 24-hour support. Magalu Cloud’s pricing page exposes product-level prices, while its service terms distinguish generally available services with defined objectives from preview features without an applicable objective. These are provider claims and terms, not proof of better outcomes. They show the documentary specificity against which Vertix quotations can be tested.
Exit begins before the first migration
Local support can reduce the friction of entering a service and simultaneously increase dependence on the provider’s people. If Vertix configures servers, monitoring, routes, backups, telephony and integrations, operational knowledge may accumulate in tickets and staff memory rather than in customer-controlled artefacts. The solution is not to avoid managed service. It is to make portability part of implementation.
For compute and virtual data-centre services, the buyer should establish supported export formats, image compatibility, snapshot access, configuration export, API availability and the time and cost to extract large datasets. For managed databases, it should test logical and physical export, version compatibility, encryption keys and continuous replication to a neutral destination. For backups, it should determine whether copies can be restored without Vertix’s control plane and whether the customer can periodically receive or verify an independent copy.
Network exit requires the address questions described earlier. DNS accounts and registrar access should be under customer control or have an emergency transfer procedure. Certificates, firewall rules, VPN configurations, route policies and partner allow lists need inventories. If provider-assigned IPv4 must be replaced, the exit plan should budget dual running and external coordination. If Vertix manages SD-WAN equipment, ownership, licences, configuration export and return terms should be explicit.
Telephony introduces number portability, recordings, call-detail records, greetings, queues, integrations and emergency routing. Vertix’s stated seven-to-15-business-day portability window is a company claim useful for planning, not a guarantee that every carrier or number type will move on that schedule. The customer should test export formats and establish who owns numbers and recordings, how consent and retention are managed, and what fallback operates during porting.
Monitoring creates quieter switching costs. Historical performance and incident data may be needed for audit, capacity planning and SLA disputes. Vertix says reports can be exported in formats including PDF, CSV or Excel and that APIs, webhooks and business-intelligence integrations are available. The buyer should export a representative dataset during the trial, confirm timestamps and identifiers remain intelligible, and document removal of installed collectors and credentials at termination.
The contract should state notice periods, data-return format, assistance rates, deletion timetable, credential revocation, overlapping-service support and confirmation of disposal. An exit drill need not migrate production during procurement. It can export one machine, restore one database elsewhere, recreate one monitor and replace one address in a test integration. That small exercise reveals whether the customer is buying a managed capability or an undocumented dependency.
Security claims must be attached to a service boundary
Vertix’s public pages mention controls including firewalls, denial-of-service protection, SSL, malware scanning, backups, a web-application firewall on one hosting tier, and TLS or SRTP for telephony. These are first-party descriptions of features. Their security value depends on architecture, configuration, monitoring, ownership and scope.
A firewall can sit at a network edge, host or application layer, each blocking different threats. A WAF can reduce common web attacks but does not fix application authorisation. TLS protects a connection when certificate, protocol and endpoint controls are sound; SRTP protects media under a correctly implemented voice design. Malware scanning may be periodic or continuous and may cover files but not memory or credentials. Denial-of-service mitigation may be delivered by an upstream and may impose thresholds, diversion procedures or charges.
The buyer should ask for a control matrix by product: tenant isolation, hypervisor or container hardening, patch responsibilities, vulnerability scanning, penetration-test scope, multifactor authentication, federation, privileged-access approval, session logging, customer audit logs, encryption at rest and in transit, key management, secrets handling, endpoint protection, backup isolation and secure deletion. Evidence might include policies, architecture, redacted test summaries, certificate scope, screenshots from a demonstration tenant and contract clauses. No single badge should be allowed to imply all of them.
LGPD makes incident workflow especially important. The ANPD provides a security-incident communication channel and guidance, but the customer as controller may depend on its provider for fast facts: affected data, people, safeguards, duration, containment and likely harm. Vertix’s agreement should define how quickly it notifies the customer, who investigates, which forensic data is preserved, how subprocessors report, and who approves external communication. The provider’s notice target must be shorter than the customer’s own decision deadline.
Security also returns to the second clock. An emergency responder should have enough authority to contain harm without relying on shared credentials or informal messaging. The exercise should test identity verification, break-glass access, approval, logging, revocation and evidence delivery. A local human who answers quickly is valuable; a local human with excessive standing privilege is a different risk. Assurance requires both speed and controlled authority.
Facility and supplier dependence needs names
Cloud architecture is a supply chain even when the commercial relationship feels personal. Vertix may depend on facilities, transit networks, internet exchanges, hardware vendors, virtualisation or container software, backup software, monitoring components, messaging channels, telephone carriers, certificate authorities and channel partners. Public routing can reveal adjacencies, but it cannot establish the commercial relationship or the physical path.
For example, public collectors observe AS53061 and AS53062 in Vertix’s routing neighbourhood, and other observed paths may include regional or national networks. A CIDR Report view can help expose collector-visible adjacency, but its relationship labels are inferred from routing data rather than contracts. Likewise, a path observed through BR.Digital does not prove that Vertix houses equipment in a BR.Digital data centre or buys a particular service from it.
Procurement should ask Vertix to name material suppliers under confidentiality and identify which are single points of failure. For each facility: legal operator, city, power design, generator and fuel assumptions, cooling, fire protection, access controls, carrier entrances and distance from the recovery site. For each network: role, contracted capacity, diverse path, routing policy, denial-of-service process and escalation. For each software control plane: hosting location, support entitlement, end-of-life policy, export capability and contingency if the vendor is unavailable.
The purpose is not to demand hyperscale disclosure from a small provider. It is to find correlated failure. Two upstream contracts that share one fibre route are not path diversity. Two backup copies in one storage cluster are not site recovery. A 24/7 support label that ultimately depends on one specialist is not full skill redundancy. A monitoring alert sent through the same failed internet connection may not reach anyone.
Vertix can turn supplier dependence into a strength by showing it is deliberately managed: diagrams, health checks, escalation contacts, maintenance coordination, capacity reviews and exercises that remove one dependency at a time. The four-clock drill should include at least one third-party handoff, because that is where local accountability is either proven or diluted.
Competition is a choice about operating labour
Vertix should not be compared with larger providers by counting catalogue items alone. The buyer is choosing who performs work, how visible that work is and how much control remains.
AWS’s São Paulo region page describes three availability zones, a large service catalogue, Brazilian data-residency options and a broad set of audited compliance programmes. Those are AWS’s claims, but they represent a different procurement model: extensive self-service controls and documentation, a shared-responsibility framework, and a need for the customer or a partner to design and operate the workload correctly. AWS can be local in data location while support and architecture remain globally organised.
Magalu Cloud is a Brazilian alternative with public product pricing and terms that distinguish service maturity. Locaweb combines domestic cloud positioning, published components and support claims. Colocation gives a customer more direct hardware and network control but leaves lifecycle, remote hands, spares and much of recovery with the customer. A managed-services integrator on top of a hyperscaler can provide a local human layer while preserving access to a large platform. A second regional provider can be used as a recovery target. Self-hosting preserves control but requires staffing, capital and discipline.
Vertix’s plausible advantage lies in reducing coordination across infrastructure, communications and monitoring for customers that do not want to assemble those capabilities. Its potential disadvantage is that a buyer may receive less public documentation, fewer independently observable operating years and more dependence on provider personnel. Neither outcome follows automatically from size. It follows from the contract, tooling, architecture and test results.
A fair evaluation should give every option the same workload and four clocks. Price the complete operating model. Trigger the same synthetic failure. Restore the same data. Ask for the same evidence. Attempt the same export. A hyperscaler may win on platform controls and failure-domain choice; Vertix may win on human ownership and integrated local execution; colocation may win on physical control. The procurement result should be a workload placement decision, not a provider league table.
A 30-day proof programme
Vertix’s public detail is sufficient to design a compact proof programme before a material migration. It need not expose sensitive production systems or turn procurement into a six-month audit.
Days 1–5: identity and boundary. Reconcile the proposal, CNPJ, invoice party, ASN registrant and data-processing party. Obtain the product responsibility matrix, supplier map, support tier, service locations, data-flow diagram and standard contract. Mark every claim as contractual, technical design, demonstration result or marketing statement. Resolve who owns DNS, addresses, encryption keys, backups and incident command.
Days 6–10: architecture and observability. Build a small representative service with an authenticated synthetic transaction. Use both external and internal signals. Confirm probe locations, five-minute or custom frequency, retry logic, correlation, severity mapping, notification routes, data retention and export. Disconnect one monitor dependency and verify an independent path still alerts.
Days 11–15: ownership and security. Trigger a declared critical exercise. Measure alert, acknowledgement, qualified-engineer engagement and incident-command times. Verify identity before granting access. Execute a pre-approved change using break-glass procedure, capture the audit trail and revoke access. Route one escalation through a named supplier or partner.
Days 16–20: recovery. Delete or corrupt a test dataset, restore it into isolation and validate the application. Measure actual RPO and RTO. Simulate loss of a host or path. If geographic recovery is in scope, operate from the recovery location long enough to expose DNS, address, licensing, capacity and support dependencies. Reconcile restored data, not just infrastructure state.
Days 21–25: routing, locality and cost. Validate the current ROAs and reachability from networks performing route-origin validation. Map IPv4 and IPv6 origins for the proposed products. Trace data, backup and telemetry locations. Run a normal, peak and incident-month bill model, including support, restore labour, traffic, public addresses, licences and tax.
Days 26–30: evidence and exit. Ask Vertix to deliver the exercise timeline in the format expected after a real incident. Calculate the SLA result under the draft contract. Export a machine or dataset, monitoring history and configuration to a neutral environment. Transfer or lower DNS safely, remove one installed monitoring collector, revoke credentials and obtain a deletion plan. Record unresolved conditions as acceptance criteria rather than allowing them to disappear into meeting notes.
The four-clock score should show both median and worst observed time where repetitions are safe, identify the party controlling each delay, and distinguish provider failure from customer approval time. A successful programme does not prove that no future incident will occur. It proves that the buyer and Vertix share an observable operating method.
The evidence gaps worth watching
Vertix’s public footprint is changing quickly enough that watchpoints matter. AS275716 was assigned in March 2026 and appeared in public routing observations soon afterwards. A young routing domain may add upstreams, exchange connections, address space, facilities and operational history. Buyers should recheck authoritative and collector data at decision time rather than treating this July 2026 snapshot as permanent.
The first watchpoint is route hygiene: current ROAs, the status of the observed more-specific IPv6 route, filtering policy and reachability through validating networks. The second is topology disclosure: whether Vertix publishes or privately provides named facilities, upstream roles, capacity and tested diversity. The third is address independence: which products use Vertix-originated space and which use provider-assigned IPv4.
The fourth is operational transparency. A public status page, historical availability, maintenance archive or redacted incident review would make the fourth clock easier to assess. This research did not locate those materials, but they could exist privately or appear later. The fifth is recovery evidence: dates, scope and results of restore and failover exercises. The sixth is support evidence: severity-specific acknowledgement and engineer-engagement distributions rather than a general average.
The seventh is security scope. Any ISO 27001 claim should be tied to the certificate holder, facilities and services the buyer will use. Product-level identity, logging, encryption and vulnerability controls should become clearer as the portfolio matures. The eighth is commercial portability: complete cloud pricing, traffic and address charges, support and project rates, export formats and exit assistance.
The ninth is customer proof. This research did not locate a verified public Vertix case study that identifies a production workload, architecture and measurable outcome. References supplied privately can help if the buyer asks about failure and exit as well as implementation success. The tenth is organisational resilience: on-call depth, partner boundaries and continuity as the service catalogue grows.
None of these watchpoints converts missing public proof into a negative finding. They are a schedule for reducing uncertainty. A provider that can answer them with current artefacts gains an advantage over a larger competitor that cannot connect its documentation to the buyer’s actual workflow.
Assurance begins after the alert
Vertix has crossed an important threshold for serious evaluation. Its identity is supported by a matching company presence and authoritative internet-resource assignments. Its network is publicly observable. Its product pages expose enough detail—five-minute monitoring, tiered support, backup retention, migration, hosting prices, telephony terms and integrations—to design tests rather than rely on slogans.
Those signals do not yet collapse into a reliability conclusion. The company’s own ASN does not prove facility resilience. A Brazilian address does not map every data copy. A five-minute check does not guarantee an authorised response. A successful backup does not prove restoration. A 99.9% hosting statement does not define every product’s remedy. Locality becomes operational assurance only when those transitions are measured.
The decisive procurement moment is therefore the hypothetical 02:13 alarm. If Vertix detects the customer-visible failure, places it promptly with a securely authorised engineer, restores the business within the agreed objective and supplies evidence that survives an SLA review, its local service model has demonstrated something valuable: not merely proximity, but compressed coordination under pressure. If any clock is undefined, the buyer has found the next contract clause, architecture change or exercise to require.
That is a demanding test, but it is fair to a small provider. It judges Vertix on the work it proposes to absorb, not on the size of its logo or the age of a competitor. The red signal is not the verdict. What happens on the four clocks after it is.