Ozbay Bilisim Internet Hizmetleri and the service records behind Turkish internet operations

Summary

• Ozbay Bilisim Internet Hizmetleri is most usefully read as an operating-record problem, not as a generic internet-company label. The important question is whether domain, hosting, server, cabinet, account, support, DNS and routing records remain fresh, attributable, queryable and recoverable when customers need repeated changes.
• Public evidence supports OZBAY BILISIM INTERNET HIZMETLERI LIMITED SIRKETI as the registrant behind AS203511. RIPE RDAP lists AS203511 as AS-OZBAY, registered on August 2, 2022 and last changed on November 11, 2025, while the registrant organization record was registered on June 9, 2022 and last changed on May 13, 2026.
• RIPEstat showed AS203511 announced in the current query window, but with a narrow routed footprint: one announced IPv4 prefix, 45.151.2.0/24, 256 IPv4 addresses, visibility from 326 of 326 listed IPv4 RIS peers, and no currently announced IPv6 space in the routing-status output.
• RIPEstat's routing-consistency data also showed two IPv6 /48 records present in whois but not in BGP, and an additional peer listed in whois but not in BGP. That is not proof of a fault, but it is exactly the kind of registry-versus-route distinction customers should test before depending on a service.
• The official Ozbay site presents a broad service surface: web hosting, corporate hosting, reseller hosting, VDS, dedicated servers, physical server colocation, cabinet rental, domain registration or transfer, SSL certificates, a customer login, published contact points and Turkey-location claims. Those pages establish public offerings and account surfaces, not measured service performance.
• The unresolved limits are material. The public pack does not include direct product testing, private customer references, SLA documents, outage history, support-ticket timing, backup logs, facility certification evidence, security reports, financial data or proof that every advertised product is delivered over AS203511.

The real product is state that does not drift

Ozbay's public footprint looks like a familiar small-provider service menu at first glance. The official site presents web hosting, corporate hosting, reseller hosting, VDS servers, dedicated servers, physical server colocation, cabinet rental, domain registration, domain transfer, SSL certificates, published contact points and a customer-login surface. RIPE and PeeringDB records present AS203511, an autonomous-system identity, an organization name, an address in Duzce, a maintainer and abuse-contact structure, and one visible routed IPv4 block.

DNS checks connect the public domain to Ozbay-controlled host names, mail records and a control-panel style reverse-DNS name.

Those surfaces are not separate stories. They describe the same operational problem from different angles. A hosting provider is not only selling disk, RAM, bandwidth or a line in a product table. It is selling the customer's ability to ask for a change and have the provider's systems agree about what the customer owns, which service is active, which IP address is in use, which contact may approve work, which invoice state applies, which server or cabinet is affected, which backup exists and which recovery path is available. The value of the service depends on that shared record surviving everyday operational pressure.

That is why the useful question for Ozbay is not whether the site uses the language of hosting, servers or internet services. It does. The sharper question is whether the records behind those labels remain synchronized enough to support repeatable operations. A domain product requires registrar state, name-server records, DNS-zone history, owner identity, renewal status, contact authorization and recovery procedures. A VDS product requires a virtual machine record, IP assignment, operating-system image, console access, power state, bandwidth policy, storage allocation, abuse handling and support escalation.

A colocation product requires rack, power, access, traffic, cabling, remote-hands, visitor authorization and incident records. A dedicated server requires hardware inventory, replacement procedure, remote access, monitoring, support scope and cancellation workflow.

If these records align, a smaller provider can be useful because the customer does not have to build every operating process alone. If they drift, a broad service menu becomes expensive. A customer may discover that a DNS record points to one place, the billing panel shows another service state, a support contact is no longer current, a route object has not been updated, a backup is assumed rather than proven, or a migration was approved by the wrong person. None of those scenarios is proven in the public evidence. They are the ordinary failure modes of this provider category, and they are the right diligence frame for Ozbay.

The evidence pack supports an operating surface, not a service-quality verdict. The site and registries show that Ozbay has public service pages, contact details, DNS and mail records, AS203511, a PeeringDB network entry and one currently announced IPv4 prefix. They do not show how quickly tickets are answered, whether a given server can be restored, whether a cabinet has dual power, whether a route change is peer reviewed, whether an advertised support channel is staffed at all hours, or whether customers receive the performance implied by product-page language.

The responsible reading is therefore narrow and practical: Ozbay is a provider to diligence through service records, not through branding alone.

Identity is clearer in registries than in marketing claims

The strongest public identity anchor is the RIPE record set. RIPE RDAP identifies AS203511 as AS-OZBAY, with start and end autonomous-system number 203511. The registrant entity is OZBAY BILISIM INTERNET HIZMETLERI LIMITED SIRKETI, and the address in the RDAP organization record points to Serefiye Mahallesi, Zubeyde Hanim Sokak, No:9/Z8, Merkez, Duzce, Turkey. The organization record also exposes an info email address and telephone fields. The autonomous-system RDAP record lists an administrative and technical group, a maintainer entity and an abuse contact role with an abuse mailbox at the Ozbay domain.

That matters because identity drift is one of the first risks in a hosting and network-services provider. The customer needs to know whether the provider named on the invoice, the provider named in registry records, the provider behind the public website, the provider managing abuse contacts and the provider responsible for routing are actually the same operating party.

In Ozbay's case, the public registry trail is coherent enough to support a single diligence file: OZBAY BILISIM INTERNET HIZMETLERI LIMITED SIRKETI, AS203511, AS-OZBAY, OZBAY-NET for 45.151.2.0/24, the Ozbay domain, and Duzce contact details all point into the same general operating boundary.

The official website adds commercial identity. It presents Ozbay Bilisim as a Turkish provider with Turkey-location messaging and a physical-contact page in Duzce. The homepage also displays credibility claims around technical support, experience, customers and cabinets. Those claims are useful because they show the public sales posture. They should not be converted into independent facts unless a buyer receives supporting records. A number on a homepage is not a customer audit. A cabinet count on a marketing section is not a facility inventory. A support phrase is not a ticket metric.

A location label is not proof that every relevant service, backup, control panel, monitoring tool and support workflow stays in Turkey.

The PeeringDB network entry adds a network-facing identity signal. It lists the network name as Ozbay Bilisim Internet Hizmetleri, ASN 203511, website at ozbaybilisim.com, an open general peering policy, a record created on March 30, 2023 and updated on April 6, 2026. It did not show exchange or facility attachments in the captured API output. That is useful context because it says the network has chosen to appear in a peering database, but it does not prove operational depth. A PeeringDB entry without public facility or exchange attachments is a contact and identity signal, not a peering-performance proof.

The identity evidence is therefore good enough to locate the operator but not good enough to infer service maturity. Buyers should treat the RIPE organization, ASN, prefix, abuse contact, website, contact page, contract documents and customer portal as one file. If they are choosing a service that depends on routing, hosting or recovery, they should ask whether every operational contact and contract record is current. The public record shows recent change dates on the RIPE organization and PeeringDB records, which is a useful freshness signal.

It does not prove that every route object, customer record, service package, backup obligation or support roster is equally fresh.

The official service menu is broad

The official site places Ozbay in a mixed hosting and internet-services category rather than in a single narrow product lane. The navigation includes domain registration and transfer, web hosting, corporate hosting, reseller hosting, VDS servers, dedicated servers, server colocation, cabinet rental and SSL certificates. The homepage also points to a customer-login surface and contact routes. This menu is commercially important because it implies a bundled operating surface. A customer could plausibly come to Ozbay for the domain, the hosting account, the virtual server, the dedicated machine, the cabinet, the certificate and the support path.

The VDS page is the clearest cloud-adjacent public surface. It presents VDS server packages with CPU, RAM, disk, traffic-speed and IP-address fields, and it supports both Linux and Windows operating-system language. It also uses product-table language around provisioning and management. That establishes that Ozbay publicly sells virtual server capacity. It does not establish the virtualization platform, storage layout, oversubscription policy, backup model, host-level security, customer isolation, monitoring, abuse handling, snapshot policy, migration support, API availability or actual performance under load.

Those are the facts that decide whether a VDS is operationally safe.

The dedicated-server page moves from virtual capacity to hardware. It presents server packages, processor and memory details, disk details, IP-address fields and control language. Dedicated servers change the diligence question. The customer should ask what hardware inventory actually exists, whether replacement parts are available, how remote reboot works, what happens if a disk fails, what network handoff is included, who manages operating-system security, how abuse or DDoS incidents are handled, whether the provider offers reinstall media, and what access the customer has during an outage.

The public page establishes product category, not execution quality.

The colocation and cabinet-rental surfaces raise different questions again. Ozbay's server-colocation page describes physical server hosting and includes location, power, uplink, traffic and rack-space fields. The page also uses data-center quality language, including a Tier-3 phrase in the captured public text. Cabinet rental implies rack-level responsibility, power use, traffic allocation and physical access rules. Those are high-consequence records.

A buyer should ask for the facility name, certification scope, access-control policy, power redundancy, cooling redundancy, remote-hands procedure, traffic measurement method, cabinet assignment, camera and visitor logs, incident-notification rules and exit process. The public page alone cannot prove those conditions.

The domain, hosting and SSL surfaces make account-state discipline even more important. A domain name can appear simple, but it is usually the identity root for email, hosting, certificates, control-panel access and recovery. A hosting plan depends on name servers, DNS zones, mail routing, database records, file storage, certificates, account ownership and renewal timing. SSL certificates require validation records, renewal automation and private-key handling. If one provider manages several of these layers, convenience rises, but the blast radius of a stale record rises too.

A customer's account contact, payment state, DNS control and recovery process need to be precise.

The official pages are commercially useful because they define the service categories a buyer can ask about. They are not a substitute for procurement evidence. Public service pages rarely disclose what happens during a power event, a host failure, a route leak, a control-panel compromise, an abuse escalation, a customer migration, a disk restore, a billing dispute or an expired domain. Those are the cases that matter. Ozbay's broad menu should therefore be treated as a checklist, not as proof. Every listed product should map to a responsible system, support queue, recovery record and contract term.

AS203511 is strong evidence, but it is a small surface

AS203511 is the most concrete technical anchor in the public pack. RIPEstat's AS overview identifies the resource as 203511, holder AS-OZBAY OZBAY BILISIM INTERNET HIZMETLERI LIMITED SIRKETI, and announced true. RIPE RDAP identifies the autnum as AS203511, name AS-OZBAY, registered on August 2, 2022 and last changed on November 11, 2025. The registrant organization record was registered on June 9, 2022 and last changed on May 13, 2026. Those records show that the company has a public autonomous-system identity and that its RIPE organization record has recent maintenance.

The routed footprint is narrow. RIPEstat's announced-prefixes endpoint returned one announced prefix for AS203511 in the current capture: 45.151.2.0/24. RIPEstat's routing-status endpoint reported that prefix as the last-seen route, with visibility from 326 of 326 listed IPv4 RIS peers in the query window and 256 announced IPv4 addresses. The same output reported no IPv6 prefixes and no IPv6 /48 equivalents announced for AS203511, with zero of 322 listed IPv6 RIS peers seeing an IPv6 route. RIPEstat's prefix-overview endpoint for 45.151.2.0/24 also showed the prefix as announced by AS203511.

That combination tells a disciplined story. The ASN is not dormant in the captured view. It has an announced IPv4 route and global RIS visibility for that route. But it is not a broad public routing footprint in the evidence pack. One /24 does not prove a large access network, multi-site hosting estate, diversified transit strategy, or comprehensive cloud infrastructure. It is enough to anchor the provider's routing identity and to ask precise questions about how Ozbay uses that prefix. It is not enough to infer private scale.

The routing-consistency data is especially useful because it shows why registry and routing evidence must be separated. RIPEstat listed 45.151.2.0/24 as both in BGP and in whois. It also listed two IPv6 /48 records, 2a0f:85c1:701::/48 and 2a0f:85c1:7f0::/48, as present in whois but not in BGP in the captured output. It listed one peer, AS48678, as present in both BGP and whois for imports and exports, and another peer, AS215242, as present in whois but not in BGP. These are not automatic defects.

Networks often hold route objects, customer routes, planned resources, delegated records, retired records or policy records that are not currently visible in BGP. But for procurement, they are exactly the signs that a buyer should ask about.

The prefix record itself also matters. RIPE RDAP for 45.151.2.0/24 identifies the range as OZBAY-NET, type SUB-ALLOCATED PA, country TR, registered on December 13, 2022 and last changed on September 11, 2023. The linked entities include the Ozbay organization, technical and administrative roles, maintainer references and the abuse role. That supports attribution of the currently announced /24 to the company boundary. It does not say which customers, services, servers, control panels or mail systems sit inside the range.

The DNS checks show the website domain resolving into this general resource story. The apex domain returned 45.151.2.196, and the web host resolved to the same address. Mail was routed through mail.ozbaybilisim.com, SPF included 45.151.2.195 and 45.151.2.196, and reverse DNS for 45.151.2.196 pointed to srvcp.ozbaybilisim.com. Those facts suggest the public site, mail and control-panel naming sit close to Ozbay's own IPv4 footprint. They do not prove redundancy, mail security, DNS failover, DDoS protection, portal availability or customer isolation.

This is the central technical conclusion: AS203511 is real evidence of a network-resource operating surface, but it is not a service-level proof. It tells customers what to ask about. Which products use 45.151.2.0/24? Are customer VDS servers numbered from that range? Are mail, control-panel, DNS and web services isolated from customer hosting? Is there upstream diversity? Are route objects and RPKI records current? How are abuse reports handled? What happens if the /24 is filtered, blacklisted, attacked or withdrawn? The public record opens those questions; it does not answer them all.

Account and support records are the quiet control system

For a provider like Ozbay, the customer-account system is not administrative background. It is part of the product. The homepage exposes a customer-login route, while DNS and reverse-DNS observations show control-panel style host names around the public domain. The official menu includes products that require repeated account changes: domain renewals, hosting upgrades, VDS provisioning, dedicated-server changes, colocation access, SSL renewal and support requests. If the account record is wrong, the technical product becomes harder to operate even if the underlying server or route is healthy.

Account-state drift is often mundane. A customer upgrades a hosting package but disk or bandwidth policy is not updated. A domain is transferred but name-server responsibility is unclear. A certificate expires because billing and validation records disagree. A VDS is reinstalled, but reverse DNS, firewall rules or monitoring contacts remain stale. A server is moved into colocation, but power, traffic and access records are still tied to an earlier quote. A support request arrives by phone or email, but the portal does not show the latest authorized contact. These failures are ordinary because they sit between systems, not inside one system.

The public evidence cannot show whether Ozbay's private operating process avoids those failures. It can show why the risk matters. The service menu bundles layers that depend on each other: DNS, mail, web hosting, certificates, virtual servers, physical servers, routing and support. A provider can make that bundle efficient if the customer has one accountable support path and the provider's records line up. The same bundle can create fragility if the provider lacks a reliable source of truth. Buyers should therefore ask not only what services are sold, but how service state is represented internally.

Support evidence is similarly bounded. The official site uses support language and published contact points, and the contact page identifies the Duzce address and phone path. That supports local-support reachability as a public theme. It does not prove 24-hour staffing, first-response time, escalation quality, repair time, engineering availability, incident postmortems or support backlog. Public claims around support should be treated as sales language until the provider supplies measurable commitments or a buyer observes the support process directly.

The support question becomes more serious when routing is involved. A hosting ticket may be solved at the control-panel layer, but a reachability fault may involve DNS, local firewall, provider server, provider switch, upstream transit, route object, abuse filter, DDoS system or remote customer network. If the support team cannot correlate account state with routing state, the customer loses time. A small routed footprint can be an advantage if it is well understood by the provider. It can also be a constraint if there is little public information and customers must rely entirely on support.

This is where automation should be understood practically. The core automation task is not a headline claim about artificial intelligence. It is keeping service records synchronized enough that an operator can answer ordinary questions quickly. Which domain belongs to which account? Which VDS uses which IP? Which route is expected to be announced? Which mail host handles the customer's domain? Which certificate is due to renew? Which cabinet contains the customer's equipment? Which backup, if any, is recoverable? Which contact may approve access or cancellation? A provider's real quality often appears in those small record joins.

Locality is useful only when it is named

The assignment category is global, but Ozbay's public evidence is locally anchored. The website and RIPE organization record point to Turkey and Duzce. The official pages use Turkey-location language, and the public address in registry and contact evidence sits in Duzce. For Turkish customers, that may matter. Local language, payment habits, support expectations, domain and hosting practices, abuse handling, data-residency concerns and physical server access all look different when the provider is domestic rather than purely offshore.

Locality can reduce operational labour. A Turkish small business may prefer a provider that can handle a domain, mail, hosting account, SSL certificate and virtual server in the same language and commercial environment. A company with a physical server may prefer a provider that can talk through colocation access, power and traffic in local terms. A customer with regulatory or data-handling concerns may prefer to start with a provider that has a Turkish address and local support path. Those are legitimate reasons to evaluate Ozbay.

Locality is not the same as a data-sovereignty guarantee. A provider can have a Turkish company identity while using third-party DNS, software platforms, upstream transit, mail-filtering services, billing systems, support software or monitoring tools. A domain can resolve into the provider's own IPv4 space while name servers are delegated through a global DNS provider. A server can be hosted in Turkey while backups, logs, tickets or admin access involve other systems. None of that is inherently negative. It is normal internet operations. But it means a buyer cannot treat "Turkey location" as a complete answer.

The public DNS evidence illustrates this distinction. The domain's name servers resolved to Cloudflare names in the captured DNS output, while the apex and web host resolved to 45.151.2.196 and mail-related records pointed into Ozbay-named hosts and addresses. That can be a sensible combination of third-party DNS and provider-hosted service surfaces. It can also introduce dependencies that matter during an incident. If a customer cares about jurisdiction, resilience or control, the question must become specific: which records live where, who can change them, how changes are logged, and what happens if an external provider is unavailable.

For hosting, VDS, dedicated servers and colocation, the locality questions need named answers. Where is the server? Where is the backup? What facility is used? What is the access policy? What third-party platform runs billing or support? Which staff roles can access customer systems? How are logs retained? Which upstreams carry traffic outside Turkey? What data is deleted at termination, and how is deletion verified? The public Ozbay evidence supports locality as an evaluation theme. It does not prove every workload, backup, log, support ticket or control panel remains within a specified Turkish boundary.

This matters commercially because locality can justify a provider choice only when it lowers risk or labour. If a customer needs hands-on local support, domestic invoicing, Turkish communication and a provider that can reason about local hosting and network conditions, Ozbay may be relevant. If the customer needs audited regional controls, compliance certifications, multi-region recovery documents or detailed data-processing schedules, the public record is too thin. The buyer would need private documentation before treating locality as a decisive advantage.

The commercial case is about labour, not raw plan labels

The strongest commercial case for Ozbay is not that it offers a long list of products. Many providers offer hosting, servers, domains and SSL certificates. The stronger case would be that Ozbay can reduce the customer's operating labour by making those records work together. A business that buys the domain, DNS, hosting, mail, certificate and server from one provider has fewer vendor boundaries to manage. If the provider is responsive and the records are coherent, that can be valuable. If the provider is opaque or the records drift, the customer has concentrated dependency without enough control.

This tradeoff is especially visible in migrations. A customer may move a domain, a website, a mail service, a virtual server, a physical server or a cabinet relationship to Ozbay. The public service menu suggests Ozbay can receive several of those transitions. The hard part is not the public product name. It is the transition record. Which service moves first? Which DNS TTL is lowered? Which backup is taken before the change? Which IP address changes? Which mail queue is protected? Which certificate must be reissued? Which contact is allowed to approve downtime? Which old service must remain active until validation?

Which rollback path exists?

Public evidence does not show Ozbay's migration playbook. That absence should not be turned into a negative verdict, but it should shape procurement. A buyer should ask for a written migration sequence for any service that can affect revenue, email or public reachability. If Ozbay can provide clear steps, named responsibilities and evidence of post-move validation, the provider's bundled service surface becomes more credible. If the answer is only informal support language, the buyer should keep independent backups and change-control records.

The comparison with larger alternatives is also not one-dimensional. A global cloud platform may provide better APIs, logs, managed services, monitoring, security documentation and automation, but it may require more customer expertise. A major carrier may provide wider formal network reach and more standardized service-level documents, but it may be less flexible for a small hosting customer. A local provider may provide direct help, familiar billing and bundled services, but public evidence may be thinner and private controls may need to be inspected.

Ozbay belongs in that last comparison set unless it supplies deeper technical documentation.

Price tables, where visible, cannot decide the question. A low-cost VDS may be useful for a small workload and risky for a critical service if backup, isolation and recovery are unclear. A dedicated server may be attractive if hardware access and replacement are well managed, and fragile if the customer cannot get timely hands-on support. Cabinet rental may be sensible if facility and power terms are clear, and risky if the facility evidence is just marketing text. The same service label can be a good or bad commercial decision depending on the hidden labour it creates.

The buyer's cost model should include support time, migration time, recovery time and audit time. If Ozbay can answer questions quickly, keep records current and provide local help, the service can save labour. If a customer must independently monitor every route, keep duplicate backups, audit every DNS change, chase every support ticket and document every migration step because the provider's process is opaque, the headline plan price will understate the real cost. The public record is not deep enough to resolve that balance, so the article's commercial conclusion must remain conditional.

Failure modes are ordinary, not accusations

The known failure modes for this assignment are dormant-route ambiguity, stale registry records, outage opacity, account-state drift, backup gaps, support backlog and unsupported uptime claims. Each is plausible in this service category. None is proven as an Ozbay failure by the public evidence. The useful approach is to translate each risk into a diligence check.

Dormant-route ambiguity appears when a registry or routing-policy record exists but a live BGP route is absent, or when public tools show different views of a resource. The current RIPEstat evidence shows AS203511 announced with one IPv4 /24, while routing consistency shows two IPv6 /48 records in whois but not in BGP. That can be normal. It can also confuse customers if they assume every registry-visible resource is live. A buyer should ask which resources are active for the service being bought, which are reserved, which are customer-specific, and which are historical or planned.

Stale registry records can create operational pain. Abuse complaints, upstream filters, route-policy changes and security investigations rely on accurate registry data. Ozbay's RIPE organization record has a recent last-changed date in May 2026, which is a positive freshness signal. But the IPv4 prefix record was last changed in September 2023, and a single change date cannot prove every contact, route object and policy record is current. Customers with routed services should include registry review in onboarding and periodic audits.

Outage opacity is a risk wherever public status history is limited. The evidence pack did not include a detailed public status page, incident archive or independent uptime record. That means customers should not assume public incident transparency. They should ask how Ozbay communicates outages, whether notification differs by product, who receives messages, what the support escalation path is, and whether post-incident summaries are available for business-critical services. Private support can be adequate, but only if the customer knows what to expect during a fault.

Account-state drift has already appeared as the quiet risk across the service menu. It is especially relevant when one provider handles domains, hosting, certificates, servers and contact authorization. Buyers should ask which system is authoritative for service ownership, renewal status, package level, IP assignment and support authorization. They should also keep their own export of domain, DNS, certificate, server and backup records. A provider can help manage these layers, but the customer should not be blind to them.

Backup gaps deserve blunt treatment. Public service pages may imply reliability, data-center operations or managed support, but the public record did not provide backup logs, restoration-test evidence, retention schedules or a clear division of responsibility between provider and customer. Any customer running a material workload should ask what is backed up, how often, where, how long retained, how restoration is requested, what is excluded, whether databases are consistent, whether customer-initiated deletion is protected, and when the last restoration test succeeded.

Until those answers are documented, the customer should keep independent backups.

Support backlog and unsupported uptime claims are connected. A provider can advertise support and still have slow response under load. A provider can use reliability language without publishing measured availability. The public evidence did not include ticket volumes, first-response metrics, repair-time metrics, customer references, status-page history or SLA compliance data. Buyers should therefore negotiate measurable support commitments for critical services and run their own monitoring. Ozbay's public record supports the existence of contact and service surfaces, not the quality of their operation under stress.

How to diligence Ozbay before relying on it

A practical diligence file should start with a service map. List every service under consideration: domain registration, DNS, web hosting, corporate hosting, reseller hosting, VDS, dedicated server, physical server colocation, cabinet rental, SSL certificate, mail, customer panel and support. For each one, identify the authoritative record, owner, access method, failure signal and recovery path. This turns a broad provider conversation into a series of verifiable records.

For network resources, ask directly about AS203511 and 45.151.2.0/24. Which products use the /24? Are there customer-assigned addresses? Are there additional resources not visible in current BGP? What is the status of the IPv6 /48 records present in whois but not in BGP? Which upstreams carry the route? Are route objects, prefix filters and RPKI records current? Who approves a route change? What happens if the /24 is blacklisted, filtered, attacked or withdrawn? What abuse workflow is attached to the registered abuse mailbox?

For VDS and dedicated servers, ask for the platform and recovery map. What virtualization layer or hardware pool is used? How are customers isolated? What storage backs the plan? Is backup included, optional or entirely the customer's responsibility? What monitoring is included? How are reboots, reinstallations, snapshots, reverse DNS, firewall changes and abuse cases handled? How is a failed host or disk replaced? How can the customer export or migrate data if leaving the provider?

For colocation and cabinet rental, ask for the facility map. Which data center or facility is used? What exactly does any Tier-3 language refer to? Is it a certified facility, a design claim or a marketing phrase? What power, cooling, cabinet, traffic, uplink, remote-hands and access terms apply? How are customer visits authorized? How are emergency reboots handled? How is traffic measured? What happens if the customer removes equipment or cancels service? Public pages cannot answer these questions; a serious provider relationship should.

For account and support, ask how records are joined. Which portal is authoritative for services, billing and tickets? Can phone and email requests be tied to the same ticket history? Who can approve domain changes, server reinstallation, DNS edits, cabinet access or cancellation? Are support hours different for hosting, server, colocation and network issues? What is the escalation path if first-line support cannot diagnose routing or facility problems? How are completed changes documented for the customer?

For locality and data handling, ask for named boundaries. Which systems are in Turkey? Which records or backups use third-party services? Which staff roles can access customer systems? How are logs retained and deleted? Which legal terms cover customer data? How is abuse or law-enforcement contact handled? How are credentials reset and audited? Locality has commercial value only when it is attached to specific systems and records.

What the public record can and cannot establish

The public record can establish several important facts. It supports Ozbay as a Duzce-based Turkish provider with an official website, contact surface, broad hosting and server service menu, domain and SSL offerings, customer-login surface, AS203511, RIPE organization identity, one currently announced IPv4 /24, a PeeringDB network entry, DNS and mail records tied to the Ozbay domain, and control-panel style host naming. It supports the article angle that Ozbay should be judged through service, registry, routing, account and support records rather than through internet-provider branding alone.

The public record cannot establish the facts a buyer would need for critical reliance. It does not disclose private customer contracts, actual customer count, cabinet inventory, facility certification evidence, network diagrams, upstream contracts, support rosters, ticket metrics, outage history, incident postmortems, backup logs, restoration tests, vulnerability management, security reports, penetration tests, control-panel architecture, financial resilience, measured throughput, packet loss, latency, uptime or customer references.

It does not prove that every advertised service is active, available everywhere, delivered over AS203511 or supported by the same operational team.

That limit does not make Ozbay irrelevant. It makes the provider a diligence candidate rather than a conclusion. The evidence shows enough of an operating surface to ask specific questions. The routed footprint is narrow enough that customers should avoid assuming hidden scale. The official service menu is broad enough that account-state governance matters. The locality evidence is strong enough to ask Turkish-market and data-boundary questions, but not strong enough to treat data sovereignty as solved. The support and recovery evidence is thin enough that customers should require written commitments for critical workloads.

The final judgment is therefore conditional. Ozbay can be commercially useful if it keeps the records behind its services fresh, attributable, queryable and recoverable: AS203511 and route records, DNS and mail records, customer accounts, domain ownership, certificates, VDS assignments, dedicated-server inventory, cabinet access, backup responsibilities, support tickets and incident communications. If those records hold together, a local provider can reduce customer labour. If they do not, the customer must supply the missing discipline with independent monitoring, backups, documentation and migration plans.

The public record proves the surface to investigate. It does not prove the operational outcome.