What Is upti.my-healthcheck/1.0 in My Logs?

If you are looking through server logs and noticed requests with this user agent, you are probably trying to answer a simple question.

User-Agent: upti.my-healthcheck/1.0

Is this traffic safe?

If you searched this user agent, you are probably trying to decide whether to ignore it, allow it, or investigate it. The important thing to know is that it usually appears because a specific URL is being monitored on purpose.

These checks are used to verify that websites, APIs, app login pages, pricing pages, status pages, cron jobs, heartbeats, and other important product surfaces are reachable and behaving as expected.

Why am I seeing upti.my in my logs?

You may see requests from upti.my-healthcheck/1.0 when a public URL is being monitored from upti.my.

That usually happens when:

• Someone on your team added your site or API to upti.my.
• A customer, partner, or integration depends on that endpoint and monitors it externally.
• A public product surface is being checked for availability.
• A launch, signup flow, login page, docs page, or status page is being watched for downtime.

The check is usually a normal HTTP request, similar to what a browser or uptime monitor would send, but with a clear user agent so it can be identified in logs:

User-Agent: upti.my-healthcheck/1.0

What does upti.my check?

upti.my can monitor more than a homepage.

Common checks include:

• Homepage availability.
• App login and signup pages.
• API health endpoints.
• Pricing and checkout pages.
• Status pages.
• Documentation pages.
• Cron job heartbeats.
• Background worker completion.
• Incident and alert workflows.

That matters because many outages do not look like a full-site outage.

Your homepage can return 200 while login is broken. Your pricing page can work while checkout fails. Your app can load while a background job silently stops running. Your status page can be online while the thing behind it is not.

That is the gap upti.my is built for.

Is upti.my a crawler?

No. upti.my is not a search crawler, scraper, SEO bot, or AI training bot.

It does not crawl your whole site by default. It checks specific URLs that were configured as monitors.

A normal uptime check should be lightweight:

• It requests a specific URL.
• It records status code, latency, and response result.
• It alerts when the check fails.
• It may run from multiple regions, depending on the monitor setup.

Should I block it?

Usually, no.

If the request volume is low and the paths being checked are important product surfaces, blocking the user agent may hide a real reliability issue from whoever is monitoring that endpoint.

If you are seeing too much traffic, repeated failures, or checks hitting the wrong path, the best option is to identify who configured the monitor and adjust the check.

If you believe the traffic is unwanted, you can block it like any other user agent, but that will also prevent those uptime checks from working.

Why a Visible User Agent Matters

Monitoring should be identifiable. A clear user agent helps engineering teams understand what is hitting their servers. If a request appears in your logs, you should be able to tell whether it came from a browser, a crawler, a bot, a monitoring system, or something suspicious.

That is why upti.my identifies its checks instead of hiding behind a generic browser string.

What to Monitor in Your Product

If seeing upti.my in your logs made you think about monitoring, start with the surfaces that affect users or revenue.

For a SaaS product, that usually means:

• Homepage.
• Login.
• Signup.
• Pricing.
• Checkout.
• API health.
• Docs.
• Status page.
• Cron jobs.
• Background workers.
• Webhook delivery.
• Key customer workflows.

Do not stop at GET / returning 200.

The useful question is not only: is the website up? The better question is: can users still do the thing they came here to do?

How to use upti.my

upti.my gives you uptime monitoring, cron and heartbeat monitoring, incident management, status pages, and alert workflows in one place.

If you want the same kind of visibility for your own product, start by creating checks for the paths that affect revenue, activation, and customer trust, not just the homepage.

That usually means login, signup, pricing, checkout, APIs, cron jobs, background workers, webhooks, and the workflows customers depend on every day.

You can create those checks here: https://app.upti.my

If you came here because you saw upti.my-healthcheck/1.0in your logs and want help understanding the traffic, contact us and include the URL, timestamp, and user agent you saw.

We will help you trace what the check is doing.