Docs

Type a word or a question. Esc closes the search.

DE
Sign in Start free
Guide/Look up

Troubleshooting

Find what you see on screen. Each entry says why it happens and what to do. If none fits, contact the up4 team with the monitor or page you mean.

A monitor is down, but my site works

You see a monitor marked down while the page loads in your browser. The failed check names what went wrong, for example "HTTP 403", "Check timed out", "Connection refused" or "Address not found (DNS)".

Likely causes

  • A firewall or bot protection blocks the checkers. They come from fixed addresses, listed under where checks come from.
  • The page answers a program differently from a browser, for example with a 403, or redirects while Follow redirects is off. Only a 2xx answer counts as up, unless you expect another status.
  • The server refuses the method. A monitor set to HEAD fails when the server answers 405.
  • The server needs longer than the request timeout, 30 seconds unless you changed it, at most 1 minute.
  • The name does not resolve from the checkers yet, for example after a DNS change.
  • Only some regions fail, because of a regional block or a bad route.

What to do Open the failed check and read its message. Allow the checker addresses, set the method to GET or raise the timeout as it fits. Website checks in detail.

A keyword check fails, but the word is on the page

You see a failed check with the message "Required keyword not found".

Likely causes

  • Ignore case is off. The search is then exact about capitals, and the message adds "search is case-sensitive".
  • The word sits beyond the first 1 MiB of the response. The message says "not found in the first 1 MiB".
  • Scripts add the word after the page loads. The checker reads only the HTML it receives and runs no JavaScript.
  • The page does not answer with a 2xx status, for example an error or consent page. A keyword check needs a 2xx status as well as the word.
  • The phrase contains markup or special characters, so it differs from the HTML as sent.

What to do Open the page source in your browser and search for the exact word. Shorten the phrase to one plain word. Check page content.

A check fails with a certificate error

You see a failed check on an HTTPS address with the message "TLS certificate or handshake failed".

Likely causes The certificate has expired, is not trusted, is self-signed, or was issued for another name. up4 verifies certificates unless you switch that off. The message also appears when the server and the checker find no common TLS setting.

What to do Renew or fix the certificate. For a test server with its own certificate, switch off Verify the TLS certificate. To hear about expiry early, set Certificate expiry warning. Certificates and domains.

A monitor keeps flipping between up and down

You see many short outages and all-clears for one monitor.

Likely causes The target fails now and then, for example under load. up4 already waits for 3 matching results before it changes state, so the failures last longer than a single check.

What to do Raise Extra confirmation time so a failure must last longer before it counts, and Recovery period so up4 waits for stable before the all-clear. Or choose Skip short blips for the alerts. When you get alerted.

No alert email arrives

You see a monitor that is down, or a test alert that does not arrive, and no email.

Likely causes

  • The state has not changed yet. It needs 3 matching results.
  • The monitor is paused or inside a maintenance window, so it is not checked.
  • The alert mode is Skip short blips: it alerts only once the downtime adds up to 3 minutes. A shorter outage stays in the history.
  • Nobody is selected. The form warns you: Nobody is alerted when this monitor goes down. Pick a channel or an alert plan..
  • The email landed in spam, or the address is wrong.
  • Monitoring is paused because the credit is used up, see Monitoring is paused.

What to do Select Send test alert on the monitor page, check the spam folder and add a second alert channel. Receive alerts.

The alert arrives late

You see an alert minutes after the site went down.

Likely causes The first failed check comes at the next interval; two instant re-checks follow. Extra confirmation time adds its time on the way down, Skip short blips waits for the downtime to add up, and an alert plan can wait before its later steps. After that, delivery depends on the alert channel and its provider.

What to do Shorten the interval, lower the extra confirmation time and put the people who must react first in the first step of the alert plan. When you get alerted.

A monitor stayed quiet during an outage

You see no alert and no check results for a stretch in which the site was down.

Likely causes A maintenance window was active. The checker skips a monitor's checks inside its window, so there are no results and no alerts. The window follows the time zone you set on the monitor; the form presets Europe/Berlin, so a window entered in your own local time can land hours off.

What to do Check the window's times, weekdays and time zone on the monitor. Plan maintenance.

A scheduled job shows late although it ran

You see "past its window, still inside the grace period", "grace period elapsed without a ping" or "last run reported an error" on a job that did run.

Likely causes

  • up4 counts from the last check-in, not from your cron schedule. Once the expected interval has passed the job is late; once the grace period has passed as well it is missed and up4 alerts, within 30 seconds of that moment.
  • The check-in goes out at the start of the job, or the job runs longer than interval plus grace.
  • The check-in never reaches up4: a wrong address (up4 answers 404), a proxy in the way, or a signature that does not match (up4 answers 401).
  • The job reported a failure itself, so it reads "last run reported an error" until the next good check-in.
  • Monitoring is paused. up4 acknowledges check-ins with status 200 but drops them.

What to do Send the check-in as the last step of the job, widen the grace period, and call the address by hand: a working check-in answers with status 200. Watch a scheduled job.

A new scheduled job never gets a first check-in

You see "no ping received yet" long after you set it up.

Likely causes The job has not run yet because its schedule has not come around, the address was copied incompletely, or the request does not leave your network. up4 accepts GET, POST and HEAD requests. A job that was reset when monitoring resumed after a pause waits for its next check-in the same way.

What to do Run the job once by hand and watch for status 200. Copy the address again from the job's page. Watch a scheduled job.

My status page shows an old incident

You see an incident on the public page that is long over.

Likely causes A status report you wrote by hand stays open until you post an update that resolves it. Automatic reports are opened and closed by a background job that runs periodically, so they can trail the incident by a short while. A public page is also cached briefly, so a change can take a moment to show.

What to do Open the page in the editor, find the report and post an update that resolves it. Publish a status page.

Check results look slow

You see response times higher than in your browser.

Likely causes The time covers the whole request from the region's checker to your server and back, including the connection and certificate set-up. A region far from your server shows higher times than one near it. A slow server shows the same in every region.

What to do Compare the regions of the monitor. Add a region near your visitors. To be told about slowness, switch on "Warn when the target gets slow but stays up" and, if you like, set your own value under Slower than. Slow servers.

I cannot create a monitor (402 or credit message)

You see a refusal such as "your available credit is used up", "minimum check interval for your plan is …" or "plan limit exceeded". Through the API it carries the status 402.

Likely causes The credit is used up. The interval is shorter than your plan allows. The monitor asks for more regions than your plan includes, or you reached a ceiling on the number of monitors.

What to do Select Top up balance or choose a plan, lengthen the interval or use fewer regions. Credit and plans.

Monitoring is paused

You see "Monitoring is paused" or the banner "Grace mode — balance used up".

Likely causes The starting credit is used up before a first payment: monitors and scheduled jobs pause at once. After a first payment, an empty balance starts grace mode: for 7 days checks run every 5 minutes at no charge, then monitoring pauses. Nothing is deleted, and check-ins during the pause are not counted.

What to do Select Top up balance or choose a plan. Checks continue once there is credit. Credit and plans.

A region cannot be chosen

You see a region you cannot select, marked "No active, healthy checker in this region right now", or the refusal "plan limit exceeded: regions".

Likely causes No checker in that region has reported in recently, or your plan allows fewer regions per monitor.

What to do Try again in a minute, or pick another region. Regions.

My address is refused

You see a refusal when you save an address such as localhost or one starting with 192.168, or a failed check reading "Target blocked by the network safety policy".

Likely causes The checkers sit on the public internet and cannot reach private or reserved addresses. A name that resolves to such an address is blocked when the check connects.

What to do Monitor a public address. For something inside your network, let it report out with a scheduled job instead. Watch a scheduled job.

An incident has no screenshot

You see an incident without a screenshot and a note that says why, for example "No screenshot: monitoring is paused until the balance is topped up.".

Likely causes Incident screenshots is off for the monitor, this month's allowance is used up (the note names the date screenshots resume), the site did not respond so there was nothing to capture, or monitoring is paused or in grace mode. Screenshots exist for website monitors only.

What to do Read the note on the incident and, if the setting is off, switch it on for the monitor. Handle an incident.

What up4 does not do here

  • This page covers what up4 shows and does. It cannot see inside your servers, firewalls or mail systems.
  • up4 cannot tell why a site refused a check beyond the status and message it received.