Why your scheduler should fail loudly

Building a publisher teaches you that the dangerous failures are quiet. An error message is a good day: you know, and you can act.

The expensive version is a post that never went out while every screen says it did.

Silent failure has a specific shape

It is almost always a summary that hides detail. One status field for a post that went to five networks. One “success” when four succeeded. A row that says “posted” because something posted.

We hit our own version of this while building. A workspace delete ran, returned no error, and changed nothing — because the database policy that permits deletes had never been written, and a delete matching zero rows is not an error. It looks exactly like success.

The rule we ended up with

If an operation can partly succeed, it does not get one status. Every network delivery has its own record, its own error text, and its own retry.

And if an operation affected nothing, that is reported as a failure rather than a no-op. “It worked and changed nothing” is not a state a user can act on.

Keep the log, and show it

Every delivery attempt is written down with its error. That is cheap. What is easy to skip is the screen showing it — we wrote that log for weeks before building anywhere to read it, which meant the answer to “why did that fail” existed and nobody could reach it.

A log nobody can see is not observability. It is a debugging aid for whoever has database access.

What to check in whatever you use

• ✓Post to two networks and make one fail on purpose — an over-length caption is easiest. Does the tool tell you which one failed, or just that something did?
• ✓Can you retry only the failed network, or does retrying re-post to the ones that already worked?
• ✓When a token expires, are you told before the next post fails, or after?
• ✓Is there a screen showing what actually happened, or only what was intended?