The symptoms suggest your input is not triggering your interrupt when you expect it to. Maybe you need to do some external signal conditioning before you can trigger a digital input from this.
I am, not sure why you are counting pulses over five small intervals and averaging them. Is it to avoid number overflow in rpmcount? If so, you may find that with a signed byte you still get overflow at quite low rpms. You may need to reduce the sample interval even further to avoid that if you plan to take the engine over about 2000 rpm. When your delay() interval gets small compared to the time taken to complete the loop, you may find that the overall loop period is significantly different to the nominal delay period. It's best to use the timing technique demonstrated in the 'blink without delay' example sketch to get an accurate loop period.
Otherwise, the basic logic looks as if it should produce a value for AvgRPM that matches the number of samples in the loop period.
What you do with AvgRPM to calculate ActRPM looks a bit dodgy to me. Remember that the AvgRPM you have calculated is the average number of pulses in 100 ms (ish), not in 0.5 seconds. Your comment implies a 4-stroke cycle so the engine turns twice per input pulse.
So the calculation should probably be:
ActRPM = AvgRPM * 10 * 60 * 2; // *10 converts pulse count to Hz, *60 converts to pulses per minute, *2 converts to revs per minute
rather than:
ActRPM = AvgRPM * 10 * 60 / 2;
If you are going to keep the averaging approach, RPMCount0 .. RPMCount4 are crying out to be put into an array.
The name AvgRPM is misleading since it is storing the average count per sample interval not revs per minute.
I think you could simplify this a fair bit by just accumulating pulse counts in a local variable until a long enough time has elapsed, for example a second. Then multiply the total up to get revs per minute and you are done. No need to buffer and average them. That would only be needed if you intended to produce a time average to smooth out variations over a longer period, but there's no point thinking about that type of thing until the basic instantaneous measurement is producing sensible values.