WebLens

“Uptime” and “online right now” answer different questions. A website can respond successfully when you check it and still have experienced several outages earlier in the day. WebLens separates those two ideas: Website Status is an instant check, while Website Uptime builds an observed history from repeated checks.

That distinction matters when you are troubleshooting an outage, reviewing a deployment, or trying to understand whether a service has been consistently reachable. The WebLens uptime tool starts collecting measurements when you first use it for a target, then records later checks so the reported percentages are based on observed results rather than an invented historical number.

What WebLens Uptime actually measures

For a monitored website, WebLens makes an HTTP request and records whether the public endpoint was successfully reached, the HTTP response code, and the request time. A successful HTTP response in the 200–399 range is treated as available for the uptime check. A request failure or a response outside that range is treated as unavailable.

The tool then uses the checks it has collected to calculate observed uptime over three windows: 24 hours, 7 days, and 30 days. It also shows the latest status, the current online streak, when monitoring began, the number of recent samples, the latest HTTP status, and the latest response time.

Uptime versus Website Status

The difference is simple but important. Website Status asks: Can WebLens reach this website now? Uptime asks: What percentage of the checks WebLens has recorded for this target were available during the selected period?

If you need a one-time answer, use the WebLens Website Status Checker. If you want an availability history, use the WebLens Website Uptime tool.

For example, a site might currently show ONLINE while its observed 24-hour uptime is 99.2%. There is no contradiction: the latest request succeeded, but one or more earlier checks failed.

Why the first result may say “Collecting data”

WebLens does not claim that a website was monitored before you started collecting observations. On the first uptime check, the tool creates a monitoring target and records the current result. Until enough observations exist for a meaningful time window, that window can show Collecting data.

This is deliberate. A percentage such as 99.99% only has meaning when it is based on actual checks. If monitoring began today, WebLens cannot truthfully tell you what happened last week.

How the monitoring works

After a target has been registered, WebLens schedules periodic checks. The current implementation uses a five-minute monitoring interval when WordPress cron is running. Each check records a timestamp, availability result, HTTP status when available, and response time.

That means the uptime percentage is an observed sample-based measurement. It is not the same thing as a contractual SLA and it does not represent every request made by every visitor. A short outage that occurs between two monitoring checks may go undetected.

How to read the 24-hour percentage

The 24-hour figure is calculated from the successful and unsuccessful samples recorded during the previous 24 hours. If 287 of 288 recorded checks were available, the observed availability is:

287 ÷ 288 × 100 = 99.65%

The calculation is based on samples, so the exact percentage can change when a new check arrives. It can also be affected by a failed check caused by a temporary network problem between the monitoring server and the target.

What the 7-day and 30-day numbers tell you

The longer windows are useful for seeing whether an incident is isolated or part of a recurring pattern. A 24-hour result can change quickly after one outage. A 7-day view gives you more observations, while a 30-day view provides a broader picture once the target has been monitored for that long.

Remember that the tool reports observed uptime. If monitoring has only existed for three days, the 30-day window cannot magically contain a full 30 days of evidence. The tool keeps the distinction visible through its monitoring start time and sample count.

Current online streak

The current online streak tells you how long the most recent consecutive successful checks have lasted. It is useful after an incident because you can see whether the service has remained reachable since the latest recovery.

A long streak does not erase previous failures. It simply describes the current sequence of successful observations.

What the HTTP status means

The latest HTTP status provides additional context. A 200 response usually represents a successful request, while 3xx responses indicate redirects. WebLens treats the 200–399 range as available for its uptime calculation. A 4xx or 5xx response is therefore recorded as unavailable for this specific uptime measurement.

This is a monitoring rule, not a universal definition of website health. A service could intentionally return a 404 for a particular URL while the rest of the application is healthy. Choose a target URL that represents the service you actually want to monitor.

Response time is a separate signal

Uptime tells you whether a check was considered available. Response time tells you how long the request took. A website can be technically available while becoming increasingly slow, so the latest response time is useful alongside the uptime percentage.

For deeper network latency testing, WebLens also provides a Ping / Latency tool, which measures TCP connection time to port 443. That is a different measurement from the HTTP request used by uptime monitoring.

Common troubleshooting cases

The site is online, but uptime is lower than expected

Look at the monitoring start time and sample count first. Then consider whether earlier checks failed because of an outage, a server timeout, DNS problems, or temporary network reachability. Compare the result with the site’s logs and your hosting provider’s monitoring.

The uptime percentage is still collecting data

That means WebLens does not yet have enough observations to populate that window. Keep the target monitored and allow scheduled checks to accumulate.

The site works in my browser, but WebLens reports a failure

A browser session and an automated server-side request can encounter different DNS answers, routing, access controls, TLS behavior, or application rules. Check the target from another network and inspect the HTTP Status Checker and SSL Checker for additional evidence.

I need an SLA-grade availability report

WebLens is a diagnostic and observed monitoring tool. Its sample interval and monitoring environment are not a replacement for a formal multi-region monitoring platform or contractual SLA measurement. For critical infrastructure, compare WebLens observations with your production monitoring and provider reports.

What WebLens Uptime cannot prove

An uptime percentage cannot prove that every visitor could reach the site, that every page worked, that the application returned correct business data, or that the site was healthy from every geographic region. It measures the checks performed by the WebLens monitoring environment against the target you supplied.

DNS changes, firewalls, rate limits, maintenance pages, application errors, regional routing, and third-party dependencies can all create situations where one observer sees availability and another does not.

Start monitoring a website

Enter the website URL in the WebLens Website Uptime tool to create or continue its observed monitoring record. Use the result alongside Website Status, HTTP Status, SSL, DNS, and latency checks when you need to understand why availability changed.

For the clearest troubleshooting workflow, start with the current status, inspect the latest HTTP response, then use the uptime history to determine whether the problem appears isolated or recurring.

When HTTPS stops working, the certificate is often one of the first things to investigate. An SSL checker can answer a focused question quickly: what certificate does the public endpoint present, and is it currently inside its validity period?

What WebLens checks

WebLens resolves the supplied hostname to a public address, establishes a TLS connection on port 443, reads the peer certificate, and reports its common name, validity dates, issuer, and whether the current time falls inside the certificate validity window. The checker is designed around hostnames because certificates are normally issued for domain names.

How to run the check

1. Enter the domain you want to inspect.
2. Review SSL status, common name, issuer, start date, and expiration date.
3. Compare the hostname you entered with the certificate identity shown by the endpoint.
4. If the certificate is valid but the site still fails, use the Website Status Checker and HTTP Headers Checker.

Understanding the dates

A certificate has a start and end time. WebLens marks it valid when the current time falls between those values. An expired certificate can cause browsers to block or warn about the connection. A certificate that has not yet become valid can produce a similar trust failure.

Expiration is easy to detect, but it is not the only certificate problem. A certificate can be within its dates and still fail hostname or chain validation for a client.

Common name versus hostname coverage

The checker reports the certificate’s common name. Modern certificates can also use Subject Alternative Name entries to cover multiple hostnames. If a hostname mismatch is suspected, the full SAN set should be inspected with a dedicated TLS inspection tool or the server’s certificate configuration.

Why a valid certificate can still produce an HTTPS problem

A site can have a current certificate while presenting the wrong certificate for a hostname, omitting part of an expected chain, or failing TLS negotiation for a particular client. A WebLens result showing a valid certificate is useful evidence, but it does not establish that every browser and protocol combination will accept the connection.

Certificate renewals and deployment

Automated renewal can obtain a new certificate before the old one expires. The operational step that matters is deployment: the web server, reverse proxy, or CDN must actually start presenting the renewed certificate. If renewal succeeds but the public endpoint still serves the old certificate, investigate deployment and configuration.

Limits of the check

WebLens does not present a full cipher-suite report, complete certificate-chain audit, or historical certificate timeline. Multiple endpoints can also produce different certificates when a domain uses a CDN or load balancer.

Check the public endpoint now: open the WebLens SSL Checker and inspect the certificate dates and issuer for the hostname you care about.

What to investigate when the certificate looks wrong

If the common name or certificate dates are unexpected, check which public endpoint is serving the certificate. A CDN, load balancer, reverse proxy, and origin can each have separate TLS configuration. Updating the origin certificate will not fix a client-facing certificate if TLS terminates at the edge.

If the certificate is current but users still see warnings, investigate hostname coverage, the certificate chain, system clock accuracy, and whether different network paths reach different endpoints. WebLens can provide a useful external observation, but a full browser or TLS diagnostic may expose details outside this checker.

Operational certificate hygiene

Certificate problems are easiest to avoid when renewal is treated as an operational process rather than a one-time fix. Keep track of which system terminates TLS, how certificates are renewed, and how deployment is verified. After renewal, check the public hostname rather than only the certificate files on the server. The certificate users receive is the one that matters.

An IP address is a network identifier, but by itself it is not a street address or a person’s identity. An IP lookup adds public network context around that address: where a geolocation database places it, which ISP or organization is associated with it, and which autonomous system it belongs to.

What WebLens returns

For a public IP address, WebLens queries an external IP information service and reports the address, country, city, region, ISP, organization, ASN, and timezone when those fields are available. The result is intended for network context and troubleshooting rather than precise physical positioning.

How to use the lookup

1. Enter a public IPv4 or IPv6 address.
2. Review country, region, city, ISP, organization, ASN and timezone as separate fields.
3. Use ASN and organization together when identifying the network that operates the address.
4. If the address belongs to a website, compare the result with DNS records using the WebLens DNS Lookup.

Why IP geolocation is approximate

IP geolocation databases estimate location from network and registration information. The mapped city may be a data-center location, an ISP headquarters, a regional hub, or another location associated with the address range. Mobile networks, VPNs, cloud providers, proxies, and corporate gateways make precise physical inference even less reliable.

A city shown by an IP lookup should therefore be treated as the location associated with the address in the lookup provider’s data, not proof of a person’s physical location.

What an ASN tells you

An Autonomous System Number identifies an autonomous system used to exchange routing information. In troubleshooting, the ASN can help you recognize whether an address belongs to a cloud provider, ISP, hosting company, enterprise network, or another operator. ASN and organization can be more useful than city data when tracing network ownership.

A useful example

Suppose a website resolves to an address you do not recognize. The lookup shows a cloud provider and an ASN associated with that provider. A DNS lookup can then tell you whether the domain has one address or several. Multiple addresses may indicate regions, load balancing, or CDN infrastructure.

What the lookup cannot prove

An IP lookup does not reveal a person’s name, home address, browsing history, or exact physical position. It also does not establish that the listed organization is the current owner of every service using the address. Shared hosting and cloud environments can place many unrelated domains on the same infrastructure.

Why results change

IP assignments move. Cloud workloads can change addresses, ISPs can reassign ranges, and geolocation providers update their databases. Two lookup services can disagree because they maintain different datasets. Treat the result as a current reference point when investigating an incident.

Use IP data with DNS evidence

The strongest troubleshooting workflow combines the IP lookup with DNS records, HTTP status, and latency. The IP lookup tells you about the network address; DNS explains how the domain maps to it; HTTP shows what the endpoint returns; latency adds a timing signal.

Need network context for an address? Try the WebLens IP Lookup and use the returned ASN and organization details as the starting point for deeper investigation.

Interpreting ISP, organization and ASN together

These fields answer related but different questions. The ISP may describe the network provider, the organization may identify a registered operator or business, and the ASN identifies an autonomous system. A cloud address can therefore show a hosting organization even though the actual application owner is a customer using that infrastructure.

When investigating a suspicious or unexpected address, use these fields as clues and confirm ownership through DNS, routing data, provider records, or the service configuration. Avoid treating a city or organization label as a definitive statement about a person.

Why a website can have several IP addresses

Modern services commonly use multiple addresses for redundancy, IPv4 and IPv6, geographic distribution, or a CDN. An IP lookup of one address therefore describes that address, not necessarily the entire service. Start with DNS to discover the public address set, then inspect individual addresses when a specific endpoint needs investigation.

DNS is the directory system that connects human-readable domain names with network services. When a website, API, or email service behaves unexpectedly, DNS is often the fastest place to look for an explanation. The key is knowing what each record means and what a lookup result can actually prove.

What WebLens queries

The WebLens DNS Lookup checks common public record types including A, AAAA, CNAME, MX, NS, TXT, and SOA. If the supplied target is an IP address, the tool performs a reverse lookup and reports a PTR result when one is available.

The records you will see

A records map a hostname to an IPv4 address. AAAA records provide IPv6 addresses. CNAME records alias one hostname to another. MX records identify mail servers and include priority values. NS records identify authoritative name servers. TXT records can carry public text data, including email authentication policies. SOA contains authority and zone timing information.

A practical troubleshooting sequence

1. Run the WebLens DNS Lookup for the exact domain.
2. Check whether expected A or AAAA records exist.
3. If a service uses an alias, inspect CNAME-related configuration.
4. For email problems, check MX records and then investigate mail authentication separately.
5. If you are investigating delegation, compare NS records with the DNS provider you expect.

Example: a website migration

Suppose a site moved to another host. You update the A record, but some visitors still reach the old server. DNS caches can retain earlier answers until their TTLs expire. Multiple A records can also intentionally distribute traffic. A lookup gives you the records visible from WebLens; it does not tell you what every resolver has cached.

Example: email stops arriving

If mail suddenly stops, an MX lookup is a focused first check. No MX records, an unexpected destination, or incorrect priority can explain delivery problems. A correct MX record does not prove that the receiving server accepts a particular message. SPF, DKIM, DMARC, reputation, SMTP responses, mailbox state, and filtering live elsewhere in the mail path.

Why DNS answers differ

Resolvers cache answers, providers can use geographic routing, and DNS records can change independently across authoritative servers during propagation. WebLens reports what its server can retrieve through its resolver at check time. It is a useful external snapshot rather than a universal view of every resolver’s cache.

Reverse DNS is different

When you enter an IP address, WebLens attempts a reverse lookup and reports the PTR name if one exists. PTR records are controlled separately from forward A and AAAA records. A missing PTR does not mean the IP is broken.

Limits to keep in mind

Public DNS records are only one layer of name resolution. Split-horizon DNS, private zones, VPN environments, local hosts files, resolver policies, and cached data can all produce results that differ from a simple public lookup.

Want to see the records directly? Run the WebLens DNS Lookup and use the record types to build a clear picture of how the service is connected.

Propagation is not the same as an error

After a DNS change, different resolvers can legitimately return different answers for a period because they cache records according to TTL values. That is why a change visible in one location may not appear everywhere immediately. Before declaring a DNS migration broken, compare the authoritative zone with several public resolver observations and check the record TTL.

Also remember that DNS records can be intentionally different. A CDN may use geographic answers, while an internal corporate resolver may use split-horizon DNS. A public WebLens lookup cannot see private answers that are available only inside a network.

Pair DNS evidence with the service layer

If DNS returns the expected address but the website fails, move to HTTP status and TLS. If DNS returns an unexpected address, stay at the DNS layer until the record and delegation are understood. This prevents an application symptom from being mistaken for a DNS cause.

DNS is usually the first network lookup involved in reaching a hostname. That makes resolver performance interesting when a site feels slow, especially on networks where DNS requests are frequent. But DNS speed is only one part of page performance, so a resolver benchmark should be used as a focused diagnostic signal.

What WebLens measures

For a hostname, WebLens sends DNS-over-HTTPS requests to three public resolvers: Cloudflare DNS, Google DNS, and AdGuard DNS. It measures elapsed request time from the WebLens server, keeps successful responses as timing results, and sorts available results from fastest to slowest.

The benchmark therefore describes resolver access from WebLens infrastructure. It is not a measurement of your home connection, office network, or mobile carrier.

How to run the comparison

1. Enter a domain with public DNS records.
2. Run the WebLens DNS Speed Check.
3. Compare measured milliseconds and resolver availability.
4. Repeat at different times when investigating intermittent performance.

What “fastest” means

The tool identifies the resolver that returned a successful response in the shortest measured time during that run. A difference of a few milliseconds may be real but operationally insignificant for one page load. Larger, repeatable differences can be more interesting.

Resolver caching matters. A resolver that already has an answer cached may respond differently from one that must retrieve it. TTL, cache state, congestion, and the route from WebLens to each provider all influence the result.

A useful troubleshooting example

Imagine users report that a domain occasionally takes several seconds before the page starts loading. A WebLens comparison shows all three public resolvers responding quickly. That evidence makes a widespread public resolver delay less likely from the WebLens location. Investigate the origin, CDN, TLS handshake, routing, or affected users’ local resolver next.

If one resolver is repeatedly much slower while the others remain consistent, that becomes a more specific lead. It still does not prove that the same resolver is slow for every user because the measurement path differs.

Why your result can change

Internet latency changes from minute to minute. Resolver infrastructure is distributed, the selected resolver node can vary, and WebLens runs the three requests sequentially. Each measurement therefore occurs at a slightly different moment.

What this tool does not measure

This is not a complete website speed test. It does not measure Time to First Byte, page rendering, JavaScript execution, image delivery, database latency, or local DNS cache performance. It also does not compare every public DNS provider.

Use resolver speed with DNS correctness

Speed only helps when the resolver returns the right information. If a domain resolves to the wrong address, use the WebLens DNS Lookup. If the domain resolves correctly but connections are slow, combine the result with the Ping / Latency Checker and website status results.

Ready to compare? Run the WebLens DNS Speed Check and treat the fastest result as a measurement from this checking location.

How to make a resolver comparison meaningful

Repeatability matters more than one impressive number. Run the same hostname several times and look for a consistent pattern. If one resolver is occasionally slow while the other two remain stable, record the variation instead of treating a single slow sample as a permanent property.

It is also useful to test a domain with known DNS activity and then compare the results with an ordinary DNS lookup. A fast resolver returning an unexpected answer is not useful for the application. Correctness and latency should be considered together.

When resolver speed is not the bottleneck

DNS usually occurs early in a connection, so a very slow resolver can add visible delay. But once resolution is complete, page delivery can dominate total time. If DNS checks are consistently quick while users report slow pages, shift attention to TCP connection time, TLS, HTTP response time, server processing, and assets. The speed checker is most valuable when used to eliminate one possible layer quickly.

Domain registration data is useful when you need to understand who manages a domain, when it was registered, or whether an important lifecycle date is approaching. Today, much public registration information is delivered through RDAP, the modern protocol WebLens uses for its WHOIS-style lookup.

What WebLens retrieves

WebLens sends the domain to rdap.org and reads the returned registration data. When published, the result can include the domain name, registrar, registration date, update information, expiration date, and domain status values. If the target is an IP address, the tool reports that a domain is required.

Why RDAP matters

“WHOIS” remains the familiar name for domain registration lookup, but RDAP provides a structured HTTP-based way to access registration data. Privacy rules and registry policies can limit what personal or administrative information is publicly exposed. A modern lookup can therefore return less personal information than older WHOIS examples suggest.

How to use the lookup

1. Enter the domain name you want to investigate.
2. Review the registrar and lifecycle dates that are published.
3. Read status values as registry states rather than as a general reputation score.
4. For a focused expiration check, use the WebLens Domain Expiry Checker.
5. For infrastructure questions, pair registration data with DNS Lookup results.

What domain status values mean

Registries can publish status codes describing the domain’s current state or restrictions. The exact values vary by registry and lifecycle system. A status code should be read according to the registry’s documentation rather than treated as a simple “good” or “bad” label.

A practical research example

Suppose you are researching a domain and want basic lifecycle context. The lookup can show whether registration and expiration dates are published and which registrar appears in the RDAP response. You can then investigate the domain’s DNS, website, and business ownership separately. Registration data is evidence about the domain record; it is not proof that a particular person or company controls the content served at the domain.

Why information may be missing

Not every field is publicly available. Privacy protections, registry policy, redaction, and RDAP response structure can hide or omit details. WebLens displays “Not published” when an expected value is unavailable rather than inventing an answer.

Why dates need context

Registration and expiration dates are useful operational signals, but they are not always the same thing as a guaranteed shutdown date. Registrars can renew domains, registries can apply grace periods, and lifecycle states differ by top-level domain. For a business-critical domain, the registrar account and registry rules are the authoritative source for renewal decisions.

Limits of a public registration lookup

RDAP data does not reveal private account credentials, private registrar dashboards, or a complete history of every domain owner. It also does not establish that a domain is legitimate or malicious. Reputation and content require separate evidence.

Need the public registration record? Run the WebLens WHOIS Lookup and use the returned registrar and lifecycle data as a starting point for domain research.

Registration data versus ownership claims

A registrar field tells you which registrar appears in the public RDAP record. It does not necessarily identify the person or company operating the website. Privacy services, corporate registrations, resellers, and redaction can separate the public registration record from the real-world organization behind a service.

For research, treat RDAP as one source. Compare registration data with the site’s published contact information, DNS infrastructure, certificates, and other independently verifiable records. A mismatch is a reason to investigate further, not proof of wrongdoing.

Why RDAP results can be incomplete

Different registries expose different fields and status structures. Some events or entities may be absent, redacted, or represented differently. WebLens reports what the RDAP response provides. If a field is unavailable, the correct interpretation is that it was not published in the response used for the lookup.

“Ping” is often used as a general word for network responsiveness, but different tools measure different things. WebLens uses a focused approach: it measures how long it takes to establish a TCP connection to port 443 on the target host.

What the WebLens latency test does

The tool starts a timer, attempts a TCP connection to port 443, and reports elapsed connection time in milliseconds. If the connection succeeds, the host is marked reachable. If it fails, the result is reported as unreachable. This is useful for HTTPS-hosting diagnostics, but it is technically different from an ICMP Echo Request used by traditional ping utilities.

How to use it

1. Enter a public domain or IP address.
2. Run the WebLens Ping / Latency Checker.
3. Record both reachability and TCP latency.
4. Compare with website status and SSL checks when investigating an HTTPS service.

What milliseconds tell you

Lower connection time generally means the WebLens server reached the target quickly during that test. Higher values can reflect geographic distance, routing, congestion, server-side load, or other network conditions. A single number is a snapshot rather than a permanent property of a host.

Why this is not page speed

A TCP connection can be established quickly while a website takes a long time to generate a response. After TCP, HTTPS normally involves TLS negotiation and then an HTTP request. The page may also depend on databases, APIs, images, JavaScript, and third-party services.

Conversely, higher TCP connection time does not automatically mean the application is slow. A user far from the server may experience more network latency even when the application responds efficiently.

Example: a regional complaint

Suppose users in one region report slow access while the WebLens result remains stable. That does not disprove their experience. It tells you that the route from WebLens to the host is healthy enough to establish TCP connections quickly. Compare measurements from affected networks or monitoring locations and inspect CDN or geographic routing behavior.

When an unreachable result is useful

An unreachable result can point toward a service that is not listening on 443, a firewall rule, network filtering, DNS resolution issues, or a target that is temporarily unavailable. It does not identify the exact cause. Use the Website Status Checker to see whether an HTTP request succeeds and the SSL Checker to investigate TLS.

Important limitations

WebLens checks port 443 specifically. A host that intentionally serves another service or port can therefore be unreachable to this tool while remaining operational. The measurement also comes from the WebLens server, so it cannot represent every Internet route.

Measure the connection directly: use the WebLens Ping / Latency Checker and interpret the result as TCP reachability from the WebLens environment.

How to compare latency responsibly

Latency should be compared under similar conditions. Run the same target several times and look for a pattern rather than reacting to one sample. If you are investigating a regional complaint, measurements from the affected region are more representative than a single measurement from a distant server.

Also separate connection latency from application delay. If TCP setup is fast but HTTP responses are slow, the bottleneck is likely later in the request path. If TCP setup itself is consistently slow, investigate routing, geographic distance, network congestion, and endpoint accessibility.

Use the port result as supporting evidence

A failed TCP connection to 443 and an HTTP request failure tell a more coherent story than either result alone. If TCP succeeds but HTTP fails, the service is reachable at the transport layer and the investigation should move upward. Layered evidence is more useful than a single latency number.

A service can be healthy inside a server and still be unreachable from the public Internet. A TCP port check answers the boundary question: will a connection from the WebLens server reach this port?

What WebLens tests

The WebLens Port Checker attempts a TCP connection to the host and port you provide. If the connection succeeds, the result is open. If it cannot establish the connection within the timeout, the result is reported as closed or filtered. The response also includes the host, port, and connection time.

If no port is specified, WebLens uses port 80 by default. You can supply a port such as example.com:443 to test another TCP service.

How to check a service

1. Enter the public hostname or IP and, when needed, a port.
2. Run the WebLens Port Checker.
3. Compare the state with the service you expect to be listening.
4. If a web service is involved, use Website Status or HTTP Status afterward.

Open, closed, and filtered

An open result means the TCP connection was accepted from the WebLens environment. That is evidence that something is listening and reachable on that port from this source.

A closed or filtered result is intentionally broad. The destination may reject the connection, a firewall may drop it, the service may be stopped, the host may not be reachable, or an upstream network control may prevent the connection. The checker cannot distinguish every case from the socket result alone.

Example: HTTPS works but port 80 is closed

That can be normal. A server may intentionally expose HTTPS on 443 while refusing direct HTTP on 80. If the architecture requires HTTP-to-HTTPS redirects, however, port 80 may be expected to answer. The service design determines the correct interpretation.

Example: an internal application port is not public

A database or internal API might listen on a private network while a firewall blocks Internet access. A public check returning closed or filtered can therefore be evidence that the service is not exposed externally, which may be exactly what the architecture intends.

Why location matters

Firewall policies can be geographic or source-aware. A cloud provider may also apply network controls differently from your office connection. WebLens tests from its own infrastructure, so a port can be open to WebLens and blocked from another network, or the reverse.

Limits of a TCP port check

An open port does not prove that the application protocol is healthy. A process can accept TCP connections and then return errors at the HTTP, TLS, SMTP, or application layer. A filtered result does not prove that the service is stopped.

Need a public reachability check? Run the WebLens Port Checker with the host and port you need to inspect.

Check the service you actually intend to expose

A port number is only meaningful in relation to a protocol and architecture. Port 443 normally suggests HTTPS, while port 25 is commonly associated with SMTP, but a custom application can use almost any port. Confirm which process should be listening before deciding that an open or closed result is unexpected.

For an open port, follow up with a protocol-level check. For a closed or filtered port, inspect the service listener and firewall rules from inside your authorized environment. The public result tells you what an external connection can observe; it does not replace local socket or firewall inspection.

Why filtered results are intentionally ambiguous

Network devices may silently drop connection attempts. That can look similar to a stopped service from the outside. This is useful from a security perspective because an external observer often cannot tell which internal component made the decision. Use your own firewall and server logs to identify the exact cause.

When email delivery fails, the first DNS question is often straightforward: which servers does the domain publish for incoming mail? MX records answer that question. They are routing instructions for mail systems, not a guarantee that a mailbox exists or that a message will be accepted.

What WebLens returns

The WebLens MX Lookup queries the domain’s public MX records and displays each mail host with its priority. Records are sorted by priority so you can see preferred destinations first.

How MX priority works

MX records contain a numeric preference value. Lower values have higher preference, so a sender generally tries the lowest number first and can use higher numbers as alternatives. A domain may publish one server or several for redundancy.

The hostname matters too: the MX record points to a mail server name, which then needs to resolve to reachable addresses.

How to troubleshoot

1. Enter the domain whose incoming mail you are investigating.
2. Run the WebLens MX Lookup.
3. Confirm that the returned hosts match the mail provider you expect.
4. Check priorities if multiple servers are published.
5. Use the DNS Lookup to inspect related A or AAAA records.

Example: a domain still points to the old provider

Imagine a company moved email providers but its MX records still point to the old service. New senders can continue delivering mail according to those public records until DNS changes propagate. An MX lookup makes the routing mismatch visible quickly.

Example: one mail server is unavailable

A domain with several MX records may be designed for redundancy. If the preferred server is unavailable, sending systems can attempt another eligible server according to SMTP and DNS behavior. Multiple records do not automatically guarantee resilience; the mail servers must also be configured correctly.

What an MX record does not tell you

An MX lookup does not verify a mailbox, authenticate a sender, or prove that a receiving server will accept a particular message. Delivery also depends on SMTP responses, SPF, DKIM, DMARC, reputation, rate limits, filtering, mailbox state, and provider policies.

Why an empty result needs context

A domain without MX records does not necessarily mean its website is broken. Web hosting and email hosting are separate services. A domain can serve a healthy website while intentionally having no mail service.

Propagation and caching

After changing MX records, different resolvers may hold older answers until cached TTLs expire. WebLens reports the records available to its resolver at check time. During a migration, repeat the check and compare it with the authoritative DNS configuration.

Check the routing record directly: open the WebLens MX Lookup and see which mail servers the domain currently publishes.

MX records are only the start of mail troubleshooting

Once you confirm the intended MX hosts, the next question is whether those hosts resolve and respond as expected. An MX record can point to a hostname that has a DNS problem, a service that is unavailable, or a provider that is rejecting mail for policy reasons. Use DNS and SMTP evidence together.

For authentication problems, inspect SPF, DKIM, and DMARC configuration separately. These controls influence whether receiving systems trust a message, while MX records describe where inbound mail should be delivered. Keeping those roles separate makes email troubleshooting much clearer.

Priority does not mean load balancing

MX preference values primarily express delivery preference. They should not be interpreted as a simple percentage split of traffic. If several servers have the same preference, sender behavior can vary, while higher numeric values are generally fallback choices. The receiving infrastructure must still be designed to handle the traffic it may receive.

A domain name can be central to a website, email system, API, or brand. One administrative date can therefore have a large operational impact. A domain expiry check gives you a quick view of the public expiration date reported by registry data.

What WebLens checks

WebLens uses RDAP data to retrieve the domain’s published lifecycle information. The Domain Expiry tool focuses on the domain name, expiration date, and selected public status values. If the registry does not publish an expiration date, the result says so instead of guessing.

How to check a domain

1. Enter the domain name.
2. Run the WebLens Domain Expiry Checker.
3. Review the expiration date and status information.
4. For deeper registration context, use the WebLens WHOIS Lookup.

Why the public date matters

The date is a useful operational reminder because domain registration is time-bound. If a business-critical domain is approaching expiration, verify the registrar account, renewal settings, payment method, and ownership before the deadline becomes urgent.

The displayed date should not be treated as a promise that a domain will instantly disappear at that moment. Registries and registrars can apply grace periods, redemption processes, suspension states, or other lifecycle rules.

Example: preparing for renewal

Suppose a company has several domains and wants to identify those requiring attention. The expiry checker can provide a public snapshot of dates. The next step should be an internal inventory containing the registrar, account owner, renewal policy, and business dependency for each domain. Public lookup data is a cross-check, not a substitute for the registrar account.

Why the date may be missing

Public registration systems do not expose every field for every domain. Registry policy, privacy rules, top-level-domain differences, and RDAP response structure can affect availability. WebLens reports “Not published” when the expected expiration field is absent.

What can change after you check

Renewals can extend the expiration date, and registry lifecycle updates can change status values. For a critical domain, the registrar’s own account and renewal confirmation are the authoritative operational sources. A public lookup is best used as an independent check.

Domain expiry is different from website uptime

A domain can be active while the website is offline, and a website can remain reachable while administrative problems develop. DNS, hosting, certificates, and registration are related but separate layers. If a site is not loading, pair expiry information with Website Status and DNS Lookup.

Check a domain now: use the WebLens Domain Expiry Checker to see whether a public expiration date is available.

Build renewal checks around the public date

Use the public expiration date as a trigger for an internal review, not as the moment to begin renewal. Confirm which registrar account owns the domain, who receives renewal notices, whether auto-renew is enabled, and whether the payment method is current. For a critical domain, document these details independently of one employee’s account.

If the public date differs from your registrar dashboard, investigate the discrepancy before relying on either value. Registration systems can update at different times, and lifecycle rules vary between top-level domains.

What to do when a domain looks close to expiry

First verify the registrar record and renewal status. Then confirm DNS and hosting dependencies so that a domain change does not accidentally break services. After renewal, repeat the public lookup to confirm that the registry data reflects the expected extension. The same workflow can be used as an audit trail for a portfolio of important domains.