Record when it happens rather than trying to reproduce it. Intermittent faults usually track load, a scheduled task, one specific page, or one specific user action, and the pattern identifies the cause.

Why intermittent is harder

A fault that happens every time is straightforward: reproduce it, change something, see whether it stops.

A fault that happens occasionally removes that loop entirely. You cannot tell whether a change fixed it or whether the problem has simply not occurred yet.

Which means the usual approach, trying things until it works, produces false confidence and a site with several unexplained changes in it.

The approach that works instead is to stop trying to reproduce it and start recording when it happens, because intermittent faults are almost never random.

What they usually track

Every one of those produces a pattern in time, in the page requested, or in what the visitor was doing, which is why recording beats guessing.

Record four things

The method, and it is deliberately simple enough to sustain.

Each time it happens, note the exact time, the exact address, what the visitor was doing, and the exact error text.

Ask anybody who reports it for the same four, which is a reasonable request and considerably more useful than a description.

After five or six occurrences a pattern usually appears: they cluster at a particular hour, or on one page, or only when a form is submitted.

That pattern is the diagnosis, and it converts an unreproducible fault into a specific question somebody can answer.

Without it, every conversation with a host or developer starts from nothing.

The clock is the first thing to check

Because timing patterns are common and easy to confirm.

Failures clustering at the same time each day usually mean a scheduled task: a backup, a database maintenance job, an import, or a report generation.

Those consume resource, and on modest hosting they can push the site past a limit for a few minutes.

Compare your list of times against your scheduled tasks, which you can read in the hosting panel.

Where they match, the remedy is usually to move the task rather than to fix the site: run it at three in the morning rather than at nine, or reduce how often it runs.

That is a five-minute change and it resolves a class of fault people spend weeks on.

A worked example

A business had a site returning a server error perhaps twice a day, always briefly, never when they looked.

Their host reported the server was healthy, which it was.

They started recording the four items. After a fortnight they had nine occurrences, and seven were within a few minutes of the hour.

Their hosting panel showed a scheduled task running hourly, imported by a plugin, which rebuilt a cache across the whole site.

On their plan that consumed enough memory to fail other requests while it ran.

They changed it to run twice daily, overnight, and the errors stopped.

Two weeks of recording had answered something that six weeks of trying things had not, and the fix was a schedule change rather than anything about the site.

Read the log rather than the browser

The other source, and it is more precise than any description.

The server error log records what actually failed and why, with a timestamp, and it is available in the hosting panel.

A visitor sees a generic error page. The log names a specific file, a specific line, and a specific reason, which is what somebody needs to fix it.

Look at the entries around the times you recorded, and copy the exact text.

Even if it means nothing to you, it means a great deal to whoever maintains the site, and pasting it into a support ticket is the difference between a day and a week.

Where the log has grown enormous, that is itself worth noting, since a site logging errors constantly is telling you something.

Resource limits and neighbours

The cause worth understanding on shared hosting specifically.

Shared plans allocate memory, processes, and database connections, and exceeding any of them produces an error rather than a slowdown.

That produces exactly the intermittent pattern: fine when quiet, failing when several visitors arrive together or when a heavy page is requested.

Another site on the same machine consuming resource can produce the same symptom without anything on your side changing.

Your host can confirm whether you are hitting limits, and it is a specific question worth asking rather than a general one about reliability.

Where the answer is yes, the choice is between reducing what the site does and moving to a plan with more headroom.

Change one thing at a time

The discipline that matters more here than anywhere else.

With an intermittent fault, several simultaneous changes make it impossible to know what helped, and the temptation to do everything at once is strongest precisely when the problem is hardest.

Make one change, then wait longer than the usual interval between occurrences before concluding anything.

If it happened twice a day, three days of silence means something. Three hours does not.

Keep recording throughout, since the same log that identified the pattern is what confirms whether it has actually stopped.

The counter-case

Some intermittent faults are not worth chasing.

A brochure site failing briefly once a week, where no visitor has ever reported it and no enquiry has been lost, is a cost of modest hosting rather than a problem to solve.

There is also a point at which the investigation exceeds the value: several hours of a developer's time to eliminate a fault costing nothing is a poor trade, and upgrading the plan is frequently cheaper than diagnosing why the current one is tight.

Where the site takes orders or bookings, chase it properly, since an error during a checkout is a lost sale and they compound quietly.

Record it either way, since the record is cheap and is what makes the decision informed.

What to do

  1. Stop trying to reproduce it.
  2. Record time, address, action, and error text.
  3. Ask reporters for the same four.
  4. Compare the times against scheduled tasks.
  5. Read the server error log around those times.
  6. Ask your host whether you are hitting limits.
  7. Change one thing, then wait properly.

Step four resolves a surprising share of these, and it is a comparison between two lists you already have access to.

Recording outages generally is covered in why your site went down at three in the morning.

Frequently asked questions

Why are intermittent faults so hard?

Because you cannot tell whether a change fixed it or whether the problem has simply not recurred yet, so trying things produces false confidence and unexplained changes.

What is the right approach?

Stop trying to reproduce it and start recording when it happens. Intermittent faults are almost never random and usually track load, timing, one page, or one action.

What should I record?

The exact time, the exact address, what the visitor was doing, and the exact error text. After five or six occurrences a pattern usually appears.

What is the most common cause?

A scheduled task consuming resource at the same time each day. Compare your recorded times against the scheduled tasks in your hosting panel.

Where do I find better detail?

The server error log, which names a specific file, line, and reason with a timestamp, rather than the generic page a visitor sees. Copy the exact text into any support ticket.

Is it always worth chasing?

No. A brochure site failing briefly once a week that nobody has reported is a cost of modest hosting. Where the site takes orders, chase it, since errors during checkout are lost sales.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Error that never happens when you look?

Record the exact times for a fortnight, then compare them against your scheduled tasks. They match more often than not.

Start a Conversation