"Datalogika" Ltd. sells hosted capacity that still depends on racks, transit and repair windows

Summary

• "Datalogika" Ltd. has current operating signals: its public site sells colocation in a Dolgoprudny data-centre building, the JPE.ru order panel lists rack, half-rack, single-server and rented-server products, and RIPEstat showed AS51520 announced on 12 July 2026 with 768 IPv4 addresses and wide IPv4 visibility.
• The physical anchor is unusually specific for a small host. Datalogika says its hall has 170 m2, 70 open racks, average 4.2 kW and maximum 7 kW per rack, a 400 kVA UPS, a 400 kW transformer substation, a 550 kW diesel generator, 5,000 litres of fuel and a 48-hour autonomy claim.
• The public evidence is still incomplete where customer resilience is decided. There is no public load test, certification award, upstream contract, carrier route map, spare-parts schedule, support roster, facility access procedure, backup restore record or customer migration plan.
• The best reading is a live, small Russian hosting operator with a meaningful local facility story and a visible AS, not a cloud platform whose usable capacity, physical diversity or recovery limits can be inferred from marketing alone.

The sale is a rack before it is a cloud

The word "hosted" can make a service sound elastic, but Datalogika's offer is physically blunt. The company site says it will place customer equipment in its own data centre in Moscow, and the page sells either a full rack or per-unit placement. The current public tariff section on datalogika.ru lists a rack with 4 kW from 80,000 RUB per month and per-unit placement with 0.3 kW from 3,100 RUB per month. It says the average power supplied to a rack is 4.2 kW, the maximum is 7 kW, aggregate internet channels in the data centre exceed 100Gb, and a 100Mb "Full View" internet port is included free of charge.

That is not the language of an abstract hyperscale region. It is the language of a room, a rack PDU, a cross-connect, a support shift and a bill. The same page says mounting, connection, configuration of telecom equipment and round-the-clock support are included for customers. It also advertises 100Mb, 1Gb, 10Gb, 40Gb and 100Gb interfaces, and says that, on request, Datalogika can connect a customer to any provider over a Layer 2 channel.

The promise is broad; the physical consequence is that every customer order has to consume a port, power headroom, cable path, switch capacity, technician time and a commercial relationship with the selected carrier.

The public order panel makes the offer more tangible. The JPE.ru WHMCS store page for equipment placement lists three products: single-server placement from 3,100 RUB monthly, full-rack rental from 80,000 RUB monthly and half-rack rental from 52,000 RUB monthly. A separate JPE.ru page for server rental advertises configurable servers starting at 2,350 RUB, with CPU, memory, disk, chassis and channel options. The corresponding WHMCS product page for rented servers lists "Aренда сервера - Конструктор" at the same starting price and says 100Mb/s plus one IPv4 address are included free.

This matters because colocation and rented servers fail differently. A colocated customer brings its own equipment and therefore keeps more responsibility for hardware lifecycle, operating system state, disk replacement and configuration. A rented-server customer depends on the host's spare chassis, processors, memory, drives, installation practice and remote-hands queue. In both cases, the customer's visible service may be a website, billing system, game server, mail host, enterprise application or storage node, but the recovery path starts with a person reaching a powered rack and deciding which physical component failed.

Datalogika's commercial identity is therefore a hybrid. It sells rack real estate, unit placement and hosted server capacity from the same public brand environment. Buyers should not collapse those into one promise. A 1U colocation client needs clarity on access to its own hardware, replacement media, remote-hands limits and carrier handoff. A full-rack client needs power headroom, cooling constraints, cross-connect terms and a plan for work inside the rack during shared-room maintenance. A rented-server client needs inventory, rebuild time, disk retention policy, image availability and the transfer path out of the service.

The public pages show the menu. They do not show how the kitchen behaves during a rush.

The physical anchor is unusually visible

Datalogika gives a more detailed facility description than many small hosts. The facility section of its site places the data-centre building in Dolgoprudny, Moscow Oblast, at Zhukovskogo Street 3, and says that Russian address is important for companies processing users' personal data. The footer repeats the legal name in Russian, the Dolgoprudny address, INN 5008048758, KPP 500801001 and OGRN 1085047011334. RIPE's organisation entity for ORG-DL620-RIPE also names "Datalogika" Ltd., gives country RU, gives registration number 1085047011334 and uses the same Dolgoprudny street address.

The room itself is described in operational terms. Datalogika says the hall area is 170 m2 and that 70 open server racks are installed. It names a Gamatronic Power+ UPS rated at 400 kVA and says it provides 10 minutes of operation after loss of utility power. It says the data centre has its own 400 kW transformer substation, a containerised Wilson diesel generator rated at 550 kW, a fuel reserve of 5,000 litres and enough fuel for 48 hours of autonomous operation. It says transfer from the substation to the generator happens within a minute, while the UPS carries the equipment.

Cooling is similarly specific. Datalogika says it uses Hiref precision industrial air conditioners with 76 kW of cooling capacity in a 4+1 scheme. Cold air is supplied under a 0.4 m raised floor into cold corridors. Access is described as pass-controlled, with guards, video surveillance and inert-gas fire suppression. These are useful claims because they identify the elements that have to be inspected: UPS load, generator test history, fuel contracts, cooling capacity, condenser placement, fire-panel maintenance, access control and the real amount of IT load installed in the hall.

The company also uses Tier language, but the safe reading is narrow. The site says the data centre "corresponds" to Tier 3 reliability requirements, with a separate fenced building, N+1 duplication and redundant infrastructure and communications. A Datalogika article on how to choose a data centre explicitly discusses whether a Tier III certificate exists and says certification has a cost; it says JPE oriented its work and technical equipment toward those standards and invites potential customers to evaluate compliance. Uptime Institute's Tier Classification System treats Tier certification as a formal evaluation framework, and its explanation of Tier III stresses concurrent maintainability. Unless a public award or customer-facing certificate is shown, Datalogika's Tier 3 phrasing should be read as a design and operations claim, not as proof of a certified facility.

The numbers themselves also need load context. A 400 kW transformer, 550 kW generator and 400 kVA UPS can be credible for a small hall, but the headroom depends on real IT draw, cooling load, UPS battery condition, power factor, maintenance bypass practice, generator start reliability and the number of racks actually sold at high density. Seventy racks at the advertised average of 4.2 kW would imply 294 kW of IT load before cooling and other overhead. Seventy racks at the advertised maximum of 7 kW would imply 490 kW of IT load before overhead.

The public page does not say whether every rack can draw maximum power at once, how many racks are installed and sold, or how the room allocates power when several customers ask for more.

That is the difference between installed capacity and usable capacity. Installed capacity is the equipment named on the website. Usable capacity is what remains after maintenance, heat, batteries, fuel, upstream limits, spare parts and support time are accounted for. The public facility description is strong enough to make Datalogika worth diligence. It is not strong enough to price a mission-critical migration without a site visit, load readings and a failure drill.

The company footprint supports continuity, not scale

The legal and public-service signals line up around a long-running small company. The footer of datalogika.ru gives the legal identifiers and bank details. The Russian corporate-profile page at Audit-it, citing open official records, lists the legal entity as active, gives the Dolgoprudny address, identifies the main activity as document telecommunications, says registration occurred on 16 September 2008, and reports 2025 revenue of 28.3 million RUB. ZachestnyBiznes independently presents the same OGRN, INN, registration date, active status and address.

Those corporate mirrors are not the same thing as operational telemetry. They are useful for scale and continuity, not for service quality. A 2025 revenue figure around 28.3 million RUB is compatible with a small room, a limited staff, modest colocation take-up, rented-server sales and related hosting work. It does not prove how many customers are active, how many racks are full, whether the company owns the building, how many employees are on call, how much debt is tied to facility equipment, or whether a related business holds assets outside this legal entity.

The site family gives another continuity signal. The main Datalogika page links to lk.jpe.ru for product selection and to JPE.ru branding in the customer panel. A Google public DNS query for datalogika.ru A records resolves the main site to 91.194.2.25, while jpe.ru also resolves to 91.194.2.25 and lk.jpe.ru resolves to 91.194.2.17. The NS records for datalogika.ru are ns1.datalogika.ru and ns2.datalogika.ru. Those addresses sit inside the 91.194.2.0/23 prefix originated by AS51520.

This is evidence that the public sales and account front doors are served from the same address estate that Datalogika originates. It is not a guarantee that the customer panel, billing state, service catalogue and support channels survive a loss of that estate. If the public site, store and control panel all sit in the same room and same routed block, then an outage at the Dolgoprudny facility could affect not only hosted customer workloads but also the customer's ability to open a ticket, order a replacement or read a status page. If any of those services are mirrored elsewhere, the public pages do not say so.

The service story should therefore be treated as active but small. Datalogika is not merely a parked domain with stale text: the order pages return live products, the AS is announced, the corporate identifiers remain coherent and the site advertises current monthly prices that differ from older meta descriptions on some article pages. But small active companies can still have concentrated failure paths. Continuity tells the buyer whom to call. It does not tell the buyer how many simultaneous calls the company can handle when a rack, switch or upstream goes down.

The price has to fund the repair clock

Datalogika's public prices are low enough to make the economics part of the resilience story. A single server slot at 3,100 RUB per month, a rented-server constructor at 2,350 RUB per month and a full rack from 80,000 RUB per month are not just sales figures. They are the pool from which the host must pay for electricity, cooling, fuel, upstreams, switches, optics, server parts, software, accounting, rent or property costs, tax, maintenance visits and the people who answer when something fails. The service can still be good at those prices, but only if the offer is tightly scoped and the operating assumptions are honest.

That is why the article does not treat the advertised "free" items as costless. A 100Mb included port consumes switch capacity, routing capacity and upstream headroom. Included mounting and configuration consume staff time. Moving a customer's equipment at the company's expense consumes vehicle time, packing risk and a technician's day. A free operating-system install on a rented server consumes build time and a repeatable installation practice. These inclusions can be a real advantage for a small customer that would otherwise have to coordinate several suppliers.

They can also become a queue when many customers need the same people at once.

The 2025 revenue figure reported by Audit-it gives scale context without proving service quality. Revenue of 28.3 million RUB can support a meaningful niche operation, especially if the facility is compact, staff are experienced and customers buy simple packages. It is not the kind of scale that lets a buyer assume deep spare inventory, a large bench of overnight engineers, multiple distant sites or excess transit bought for rare peak events. The fair assumption is not weakness. The fair assumption is that every promised recovery feature must be funded deliberately.

This is also why half-rack and full-rack customers should not compare only headline monthly prices. They should ask how power overages are billed, whether cross-connects carry recurring charges, whether higher-speed interfaces require a port upgrade, whether a customer can buy committed bandwidth rather than shared access, whether remote-hands tasks have time limits, and whether emergency work is priced differently from scheduled work. A low base price with paid extras can be perfectly reasonable if the contract says so. A low base price that silently absorbs high-touch recovery work can become fragile during a bad week.

For rented-server customers, the same arithmetic applies to hardware. If a 2,350 RUB monthly service includes one IPv4 address and a 100Mb path, the host has to recover the cost of the chassis, disks, memory, power, cooling, rack position and replacement time over many months. That tends to favour standard builds, limited instant replacement and careful control of unusual requests. Customers who need fast rebuilds, special disk custody, high write endurance, large memory or high commit on the network should expect to pay more or to receive a narrower written promise.

The most useful buying test is therefore not "is Datalogika cheap?" but "what does the price buy during a failure?" If the answer is a modest room, a named Russian address, practical hands-on help and best-effort rented capacity, the offer can be attractive. If the buyer needs reserved failover paths, guaranteed replacement hardware, offsite recovery and measured support response, those features should appear as paid commitments rather than being inferred from a general hosting tariff.

AS51520 is real, but routing evidence has boundaries

The strongest current operating evidence is network reachability. RIPEstat's AS overview for AS51520 identifies the holder as RH "Datalogika" Ltd. and marked the ASN announced at the 12 July 2026 observation time. RIPEstat's routing status showed two IPv4 prefixes, 768 IPv4 addresses, visibility at 326 of 327 RIPE RIS IPv4 peers and no visible IPv6 route. Its announced-prefixes view listed 91.194.2.0/23 and 94.232.251.0/24.

The registered resource picture is uneven in a useful way. RIPEstat's whois view for AS51520 shows aut-num AS51520, as-name RH, organisation ORG-DL620-RIPE, status ASSIGNED, created 16 September 2010 and last modified 24 December 2025. The 91.194.2.0/23 record ties the block to ORG-DL620-RIPE, country RU and assigned provider-independent status. The 94.232.251.0/24 record is different: it is assigned provider-aggregatable space with organisation ORG-LA1341-RIPE, and the RIPE organisation record for ORG-LA1341-RIPE names "RealHost" Ltd. in Krasnoyarsk. The route object still shows origin AS51520.

For a buyer, that means Datalogika's routed address estate should be separated into owned or Datalogika-registered space and space routed by Datalogika but registered to another organisation. The distinction is not necessarily a problem. Hosting operators often originate customer, related-company or supplier-held space. It matters during exit and incident response. If a customer service is numbered from 91.194.2.0/23, the contractual and registry control may be different from a service numbered from 94.232.251.0/24.

Address portability, abuse contact handling, prefix filtering, RPKI changes and emergency re-origination can all depend on who controls the resource and who can sign or maintain route objects.

RPKI adds the same nuance. RIPEstat's validation endpoint returned unknown for AS51520 originating 91.194.2.0/23, while the 94.232.251.0/24 result returned valid with maximum length /24. Unknown is not invalid; it means no matching route-origin authorisation was available in that validation result. A network applying strict origin validation would not reject an unknown route for the same reason it would reject invalid, but an unknown route gives less cryptographic assurance than a valid one.

Secondary routing pages broadly agree on the shape while adding more names. bgp.tools for AS51520 identifies "Datalogika" Ltd., says the AS originates two IPv4 prefixes and no IPv6, lists upstreams AS31500 Global Network Management Inc and AS5467, and shows the 91.194.2.0/23 prefix under "Datalogika" Ltd. and 94.232.251.0/24 under "RealHost" Ltd.. Hurricane Electric's BGP page for AS51520 reports two originated IPv4 prefixes, no IPv6 originated prefixes, 768 originated IPv4 addresses, 31 observed IPv4 peers and three internet exchanges: Eurasia Peering IX in Moscow, PITER-IX Moscow and Sibir-IX in Krasnoyarsk.

PeeringDB is more conservative. Its network API entry for AS51520 names "Krasnoyarsk network", links the website http://www.kraslan.ru, says the policy is open, and records one IX count and no facilities. Its netixlan entry shows an operational 10Gb port at Eurasia Peering IX with IPv4 address 185.232.60.109. The difference between PeeringDB's self-reported one-IX picture and HE's broader exchange view is exactly why an article should not equate a routing page with physical diversity. The public internet can see adjacencies; it does not see all cross-connect orders, port commits, maintenance terms, fibre entrances or shared rooms.

RIPEstat's neighbour view reported 20 observed neighbours at the research time, with AS31500 carrying by far the largest visible weight in that endpoint. That supports the assignment's hypothesis that Global Network Management is the main visible upstream, but the result still needs careful wording. "Observed neighbour" is not the same as supplier contract. Some neighbours are peers, some may be downstreams, some may be route-server artifacts, and some can appear or disappear with policy. The fact that AS51520 has multiple observed neighbours is good. The fact that one visible upstream dominates is a resilience question.

Transit diversity is not the same as restore diversity

Datalogika's own page says aggregate internet channels in the data centre exceed 100Gb and that it can provide interfaces up to 100Gb. The claim is useful but incomplete. A 100Gb-capable interface is a port option, not proof that a given customer receives a committed 100Gb path. Aggregate internet channels are not the same as uncongested failover capacity. If the largest upstream goes down, the question is how much customer traffic the surviving paths can carry without loss, jitter or commercial throttling.

This is where small-host economics become practical. A large carrier may carry spare transit, multiple city fibres, separate optical paths, a second operations centre and formal major-incident communications. A small host can still be reliable, especially if its customer mix is modest and its technical people know every rack. But a small host has fewer places to hide stress. One failed router, one saturated peer, one unavailable technician, one closed facility gate or one supplier maintenance window can affect a large share of the customer base.

The ENISA telecom security incidents 2024 report is useful here not because it says anything about Datalogika, but because it identifies common failure mechanisms across telecom incidents: cable cuts and faulty software or change updates feature heavily among technical causes tied to human error. Older ENISA incident summaries also identified system failures and power cuts as recurring drivers of outages. Those categories map directly onto a small host: civil work can cut a fibre path; a router change can leak or withdraw routes; a power transition can expose a weak UPS string; a failed disk batch can exhaust spares.

The public Datalogika offer mentions 24/7 support, included mounting and configuration, and remote hands in its article guidance. It does not publish a support roster, escalation sequence, spare-router list, cross-connect repair SLA, maintenance calendar, status page, outage archive or post-incident record. Those absences are not findings of poor performance. They are limits on what a buyer can infer. A host can have excellent private procedures and still publish little. A buyer carrying public-facing workloads should ask to see the procedures before treating the service as resilient.

The repair clock also changes by failure type. A bad disk in a rented server may be a same-day hardware swap if the part is on site and the engineer can access the rack. A failed customer-owned server in colocation may require the customer to supply parts or authorise a hands-on task. A failed UPS module may require vendor support. A fibre cut may sit with an upstream or metro carrier. A route leak may require coordination with peers, route servers and transit. Billing-panel failure may block customer action even if packets continue to flow. The customer experiences one outage; the host experiences several owners.

That is why "repair windows" belongs in the title. The service is not only sold in monthly prices. It is sold in the time between the first alarm and restored function. Datalogika's public pages are strong on room specification and product ordering, but the public record is weaker on measured restoration. The gap is where a buyer should negotiate.

Locality is a feature, but it also narrows the exit path

Datalogika explicitly sells a Russian address as valuable for companies that process users' personal data. That claim fits the market context. Stanford's WILMAP entry on Federal Law No. 242-FZ summarizes the Russian personal-data localization rule as requiring processing of Russian citizens' personal data with servers located in Russia. A Dolgoprudny room can therefore be a commercial asset for customers that want Russian-hosted infrastructure without using a larger cloud or a more expensive carrier hotel.

Locality has two sides. It can improve compliance posture, reduce travel time for Moscow-area customers, support Russian-language hands-on service and keep data-bearing hardware in a known jurisdiction. It can also reduce portability if the service relies on local IP addresses, local contracts, Russian-language support, in-room spare parts or carrier arrangements that are hard to reproduce elsewhere. A customer should know whether moving out means shipping its own servers, copying disk images to a new rented server, renumbering from AS51520 space, changing DNS, changing upstream filters or waiting for a provider-to-provider transfer.

Datalogika's facility address is particularly important for colocation customers. If a customer has regulatory, contractual or security reasons to keep a server within Russia, the Dolgoprudny room may satisfy the location requirement. But if the customer later needs a second site, an offsite backup or a hot standby, the same location requirement becomes a design constraint. A backup in another country may be unacceptable for some data. A backup in the same room may not survive the same facility incident. A second Russian site may require another provider and a tested data movement plan.

The public pages do not show such a plan. They do not advertise multi-site replication, object storage, managed backup, offsite media custody, cross-region failover or a second Russian facility. The server-rental page advertises operating system installation and configurable hardware; the colocation page advertises rack and unit capacity; the WHMCS panel accepts orders. None of those surfaces describes how a customer leaves under stress. That does not make the service unsuitable. It means the buyer owns the question.

Data locality also affects image and disk handling after failure. If Datalogika rents a server to a customer, who controls old drives after replacement? How are failed disks handled? Can a customer request destruction, return, retention or wipe evidence? If the customer places its own equipment, can the host remove media only with written approval? If the host migrates a customer to replacement hardware, where is the interim copy stored? The public record does not answer those questions, yet they are central to the promise implied by a Russian physical address.

The safest conclusion is that Datalogika can be interesting for customers that need Russian-located rack or server capacity and value a smaller operator's hands-on approach. It should not be treated as automatically portable cloud capacity. Locality is not just a map coordinate; it is a recovery and exit constraint.

Six failures define the real service

A rack power or cooling fault

The room story starts with power and cooling. Datalogika names its UPS, transformer, generator, fuel reserve and cooling arrangement. A customer should ask how those components map to its own rack. Are A and B feeds available? Does every rack have redundant power? What happens when one power path is isolated for maintenance? What is the rack-level metering interval? How close is the customer to the 4.2 kW average or 7 kW maximum? Are high-density racks spread across cold aisles or clustered? How is a cooling unit failure tested under summer heat?

The affected parties are not only the customers in one rack. If cooling is constrained, neighbouring racks can be derated. If fuel delivery is delayed, the whole room can face a shutdown decision. If UPS batteries are weaker than expected, the promised generator-start window becomes tighter. The public page says preventive maintenance does not stop the data centre. A buyer should ask for the last maintenance event in which that was demonstrated.

An upstream or peering failure

AS51520's routing is visible and IPv4-only in the public observation. RIPEstat shows two announced prefixes and 20 observed neighbours. bgp.tools lists AS31500 and AS5467 as upstreams, and HE lists three internet exchanges. This is positive evidence that Datalogika is not merely NATing behind another provider's retail broadband. It has an AS, it originates its address space and it peers or transits in public routing.

The failure question is whether the surviving paths can carry customer load. If AS31500 is removed, do all prefixes remain visible through other paths? Does 94.232.251.0/24 behave differently from 91.194.2.0/23 because the registry control differs? Are route filters, maximum-prefix limits and RPKI settings tested? Is there a documented route-change contact outside the affected room? Are the customer panel and support mail reachable through a different path? Public BGP visibility does not answer those questions; it only shows that the routes are there now.

A hardware-stock shortage

Datalogika's rented-server page advertises processors from 4 cores / 4 threads to 8 cores / 16 threads, memory from 8 GB to 96 GB, HDD from 1 TB to 10 TB, SSD from 240 GB to 960 GB, and 1U to 3U chassis with one or two power supplies. That is a configurable hardware offer, not an inventory disclosure. A small host can deliver this well if it stocks common parts and keeps clear limits on custom builds. It can struggle if a failure affects a rare chassis, a disk size no longer on hand, an old controller, a dual-PSU part or a customer that needs exact replacement.

The buyer should ask which components are stocked on site, which are ordered after failure, which substitutes are acceptable and how a server is rebuilt when the exact part is unavailable. For rented servers, the host should state whether a customer gets replacement hardware, temporary hardware or delayed repair. For colocation, the customer should know which tasks remote hands will perform and which require the customer to ship parts or attend the site.

A support bottleneck

Round-the-clock support is valuable only if the support queue has enough people with enough authority. Datalogika's public page says support is free for all customers and the article page says equipment is under continuous observation by technical-service specialists. The public record does not identify staff count, shift pattern, subcontractors, escalation authority, language coverage, ticket response targets or simultaneous-incident practice.

Small operators often win because experienced engineers answer directly instead of routing every task through a distant call centre. That advantage disappears when one engineer is responsible for too many customers or when a facility incident blocks physical access. Buyers should ask who can enter the room at night, who can perform electrical work, who can touch customer media, who can authorise carrier escalations and what happens if several customers request remote hands during the same outage.

A billing or control-panel outage

The customer front door matters. The public product pages and login flow sit under lk.jpe.ru, which resolves into the same 91.194.2.0/23 address range. The WHMCS panel is a normal way for a small host to sell, bill and support services. It also becomes part of the resilience surface. If the same facility or route failure affects both customer workloads and the panel, customers may lose the ordinary channel for tickets, orders and invoices at the exact moment they need it.

The buyer should ask for an out-of-band support route: telephone, alternate email, external status page or named escalation contact. It should also ask what happens to recurring billing if the panel is unavailable, whether service suspension logic is manual or automated, and how account access is restored after an identity or session issue. A hosted service is not only packets and power; it is also the customer's ability to get action during stress.

A migration or exit failure

The final failure is not a sudden outage but a move that cannot be completed. A customer might leave because of growth, sanctions exposure, price change, compliance change, acquisition, performance issue or the need for a second site. For colocation, exit may involve physical pickup, remote packing, customs or courier handling, data-bearing media rules and coordinated downtime. For rented servers, exit may involve image export, rsync windows, DNS changes, firewall updates, renumbering and verification that old disks are wiped or returned under the agreed rule.

Datalogika's public pages do not define data portability. They also do not show whether customers can bring their own IP space, announce it through AS51520, retain a block after leaving or move addresses to another provider. This is normal for a small public website, but it should be covered in contract terms. The worst time to learn that a host cannot produce a usable image, ship hardware quickly or maintain routes during a move is after a production service is already under pressure.

The due-diligence questions are concrete

The buyer does not need a grand audit to start. It needs a table that splits every promised service into owners and restore clocks. For power, it should ask for current rack load, UPS battery test date, generator test date, fuel contract, maintenance-bypass practice and maximum safe draw per rack during cooling impairment. For cooling, it should ask how the 4+1 Hiref design behaves when one unit is down, where temperature is measured and whether high-density racks are derated.

For network, it should ask for the actual upstream contracts, committed rates, port speeds, route-server participation, prefixes covered by RPKI, route-filter contacts and the failover test record for each prefix. It should separate 91.194.2.0/23 from 94.232.251.0/24 because the registry records differ. It should ask whether IPv6 is available even though no visible IPv6 route appeared in the RIPEstat observation. It should ask whether the customer panel, support mail and status communication depend on the same AS51520 routes.

For hardware, it should ask what Datalogika owns, what the customer owns and what a related supplier owns. It should ask for spare disks, spare PSUs, spare switch ports, optics, rails, hands-on limits and replacement timing by product. Rented-server customers should ask whether the service is backed by identical spare machines or by a build queue. Colocation customers should ask whether remote hands can swap drives, connect a crash cart, reseat memory, move a patch cord or ship failed equipment.

For support, it should ask for night access, escalation names, response and restoration targets, simultaneous-fault handling and the communication path if the WHMCS panel is unreachable. It should test the telephone and email paths before signing. It should also ask whether invoices, suspension notices and renewal events can be handled manually if the panel is down.

For locality, it should ask whether all customer data stays in the Dolgoprudny facility, whether backups are offered, whether any outsourced support sees customer systems, what happens to failed drives and what evidence is available for data-bearing media disposal. The Russian-location claim is useful only if the operational handling of media, backup and migration is equally explicit.

None of those questions is exotic. They are the ordinary questions hidden beneath a low monthly price. Datalogika publishes enough detail to make the questions worth asking. It does not publish enough to let buyers skip them.

The operating verdict

"Datalogika" Ltd. should be treated as a live small hosting operator with real public infrastructure evidence. The company has a coherent Dolgoprudny address across its own site and RIPE organisation record, a reachable JPE.ru order system, colocation and rented-server products, a detailed facility description, an announced AS, two visible IPv4 prefixes, a public abuse contact at its own domain and external routing pages that show upstream and exchange presence. That is a meaningful floor.

The ceiling is lower than the marketing language may imply. A Tier 3-aligned claim is not the same as a public certification award. A 100Gb interface option is not the same as committed failover capacity. A 48-hour generator-fuel claim is not the same as a tested multi-day incident. Multiple peers are not the same as separated fibre entrances. A Russian address is not the same as a complete data-sovereignty and exit plan. A WHMCS order button is not the same as hardware stock.

The most important evidence gap is not whether the company exists. It is how capacity recovers when the room, route, support desk and customer panel are stressed together. Datalogika's best case is attractive: a small, hands-on operator with a specific room, modest pricing, local support and enough routing visibility to serve customers who need Russian-located rack or server capacity. Its weakest case is concentration: one room, one small team, one address estate and supplier dependencies that may not be visible until a repair window opens.

That makes the buying rule simple. Use Datalogika for workloads whose risk fits a small physical host, or require proof before placing workloads that need measured failover, offsite continuity or rapid portability. The company sells hosted capacity, but the service is still made from racks, power, transit, hardware and people. The buyer's job is to make each of those elements visible before the first outage makes them obvious.