Olajide Olamide

Posted on May 25

Debugging CodeIgniter Apps From Logs Alone Was Not Enough, So I Built DEX

#php #codeigniter #opensource #monitoring

I have worked with CodeIgniter for a long time.

Long enough to know that most production bugs are not solved by just reading one error message.

The error message helps, yes. But many times the real question is not only:

What error happened?

The real question is:

What was the application doing before it failed?

That is the pain that led me to build DEX.

DEX is an open-source issue tracking tool for CodeIgniter 4 applications. It captures application issues and shows the surrounding request context, so you can understand what broke, where it happened, and what the request was doing before the failure.

The problem I kept running into

CodeIgniter already has logs.

And logs are useful.

But when you are maintaining a real application, especially one that has been around for a while, logs can quickly become frustrating.

You might see an error like:

Call to a member function getResult() on bool

or:

Undefined array key "user_id"

or:

Trying to access array offset on value of type null

The log tells you where the error was thrown.

But it usually does not tell the full story.

You still have to ask:

What route was called?
Which controller method handled the request?
What database queries ran before the error?
Was the user authenticated?
What input was sent?
Did the failure happen inside a service, model, job, or API call?
Has this happened before?
Was this issue already fixed and now it has come back?

That last one is especially painful.

Sometimes you fix a bug, move on, and weeks later the same kind of issue appears again. Without proper issue tracking, it is easy to treat it like a new problem when it is really a regression.

Logs are useful, but they are not a workflow

This is the key point for me.

Logs are records.

But debugging usually needs a workflow.

When something breaks, I want to move through the issue like this:

What happened?
Where did it happen?
What request triggered it?
What did the app do before it failed?
How often is it happening?
Is it new, ignored, resolved, or regressed?

That is different from opening a log file and searching manually.

With logs, I often feel like I am collecting clues from different places.

With DEX, the goal is to bring the story together in one place.

What DEX does

DEX captures errors and issues from a CodeIgniter 4 application and gives them structure.

Instead of only seeing a raw error, you can see useful context around it, such as:

issue status: open, resolved, ignored, or regressed
route and controller context
stack trace
request details
database queries
breadcrumbs
spans
request lifecycle waterfall

The request lifecycle waterfall is one of the parts I care about most.

I want to see a request like a timeline:

Request started
Route matched
Controller called
Database query executed
Custom span started
Exception thrown
Response returned

That kind of view helps because many bugs are not isolated. They are the result of a sequence.

The application did several things before it failed. DEX tries to make that sequence visible.

Why CodeIgniter-specific?

There are already excellent tools for error tracking and monitoring.

Sentry exists.
Datadog exists.
New Relic exists.
Framework debug toolbars exist.

DEX is not trying to replace all of those.

The goal is narrower:

Build a self-hosted issue tracking and request insight tool that feels native to CodeIgniter 4.

CodeIgniter developers often work on business applications that are practical, long-lived, and sometimes messy because they have grown over time.

Those apps do not always need a large external observability platform.

Sometimes what you need is simpler:

Show me what broke inside this CI4 request, show me the context, and help me know whether this issue is new, resolved, ignored, or has come back.

That is the space DEX is trying to fill.

A common debugging situation

Imagine a customer reports that checkout failed.

The log might show you the exception.

But that is not enough.

You may still need to know:

Was the checkout route matched correctly?
Which controller handled it?
Did the cart load successfully?
Did the payment provider call happen?
Was there a slow or failed database query?
Did the app throw the error before or after payment was attempted?
Has this same error happened before?

That is the kind of debugging experience I wanted DEX to support.

Not just:

Here is the exception.

But:

Here is the request story around the exception.

DEX is still intentionally focused

One thing I have tried to avoid is making DEX too broad too early.

It is not trying to become a full APM.

It is not trying to stream every small event live.

It is not trying to be a giant SaaS dashboard.

The focus is:

Capture useful issue context for CodeIgniter 4 applications and make debugging easier.

That means the tool is centered around issues, request lifecycle context, and practical debugging information.

I would rather DEX do that well than become a bloated monitoring tool that tries to solve every possible problem.
**
Why I made it open source**

I built DEX because I wanted to use it myself.

I understand the pain because I have dealt with it in real projects. I have opened log files, traced controller flows, followed database calls, checked sessions, inspected configs, and tried to understand why something broke in an application that was not always easy to reason about.

DEX is my attempt to make that process easier for CodeIgniter 4 developers.

DEX may be useful if you: