Well, I'm not sure whether you ask about a trigger that should fire, and does not in a particular situation, or ask more generally.

In addition to Thomas's answer, there are a few more situations I'm aware of:

1. You can generally prevent all triggers from firing (including system triggers for RI action) by setting option fire_triggers to OFF or by alternatively starting the database engine with the -gf switch - the latter preventing triggers in all databases run on that engine.
2. For AFTER UPDATE triggers: "If a column-list is specified for an AFTER UPDATE trigger, the trigger is fired only if the value of any of the columns in column-list is changed by the UPDATE statement."
3. For INSTEAD OF triggers: "If there are competing statement-level and row-level INSTEAD OF triggers, the row-level triggers do not fire."
4. Software bugs (cf. this solved one).

EDIT: Sorry, I should have read your question better - so, w.r.t. AFTER INSERT triggers, only point one could be a reason.

As to the reliability of triggers, I do rely on them. To quote from the CREATE TRIGGER page:

If an error occurs while a trigger is executing, the operation that fired the trigger fails. INSERT, UPDATE, and DELETE are atomic operations. When they fail, all effects of the statement (including the effects of triggers and any procedures called by triggers) revert to their preoperative state. See Atomic compound statements.

As such, as far as triggers are not explicitely prevented (s.a.), they should work in an atomic way.

That being said, I would only use triggers for tasks that cannot be handled by other features like

• unique and foreign keys
• datatypes, domains and defaults
• check constraints
• computed columns
• special values like DEFAULT TIMESTAMP, LAST USER and the like.

As Breck wrote in his well-knwon book: '"Avoid writing triggers." - " - if possible"*, I would add:)