Introduction

Eloquent expects timestamp columns named created_at and updated_at by default, but that convention is not mandatory. If you are working with a legacy schema or a different naming standard, you can tell the model which columns to use instead. The key is to change the model configuration, not just the migration.

Override the Timestamp Column Names in the Model

Laravel lets you override the timestamp column names with model constants.

1<?php
2
3namespace App\Models;
4
5use Illuminate\Database\Eloquent\Model;
6
7class Article extends Model
8{
9    const CREATED_AT = 'created_on';
10    const UPDATED_AT = 'modified_on';
11}

Once those constants are set, Eloquent will use created_on and modified_on when inserting and updating timestamps for that model.

Make Sure the Database Schema Matches

Changing the model alone is not enough. The table must actually contain the renamed columns.

1use Illuminate\Database\Migrations\Migration;
2use Illuminate\Database\Schema\Blueprint;
3use Illuminate\Support\Facades\Schema;
4
5return new class extends Migration {
6    public function up(): void
7    {
8        Schema::create('articles', function (Blueprint $table) {
9            $table->id();
10            $table->string('title');
11            $table->timestamp('created_on')->nullable();
12            $table->timestamp('modified_on')->nullable();
13        });
14    }
15
16    public function down(): void
17    {
18        Schema::dropIfExists('articles');
19    }
20};

If the database still uses created_at and updated_at, Eloquent cannot guess that you intended different names.

Disable Timestamps Only When You Mean It

Some developers try to rename timestamps and accidentally disable them instead. These are different concerns.

1class Article extends Model
2{
3    public $timestamps = false;
4}

That tells Eloquent not to manage timestamps at all. It is useful when the table truly has no automatic timestamp columns, but it is not the right setting when you only want custom names.

Keep Queries and Serialization Consistent

Custom timestamp names change what Eloquent writes, but they may also affect the assumptions in the rest of your codebase. Scopes, custom queries, API transformers, and validation logic may still refer to created_at or updated_at.

That means the rename should be treated as a schema convention change, not just a small model tweak. Audit the rest of the application for hard-coded timestamp column names before assuming the job is done.

This matters even more with legacy databases, where the unusual names often appear across reports, joins, and raw SQL.

If you use factories, seeders, or custom casts, review those too. Timestamp naming assumptions often hide in test data and support code, not only in production queries.

The same applies to admin tools and export jobs. Anything that orders, filters, or displays rows by timestamp may still be assuming the default Eloquent names.

Use Base Models for Shared Conventions

If many models share the same legacy timestamp naming rule, it can be cleaner to centralize the constants in a shared base model.

1<?php
2
3namespace App\Models;
4
5use Illuminate\Database\Eloquent\Model;
6
7abstract class LegacyModel extends Model
8{
9    const CREATED_AT = 'created_on';
10    const UPDATED_AT = 'modified_on';
11}

Then application models can extend LegacyModel instead of repeating the same override everywhere.

Common Pitfalls

• Renaming the columns in the model but not in the database schema.
• Setting $timestamps = false when the goal was only to use different column names.
• Forgetting that raw SQL and older application code may still refer to created_at and updated_at.
• Applying the override to one model while related tables still use the default names.
• Treating a schema naming difference as if it affected only Eloquent writes.

Summary

• Eloquent defaults to created_at and updated_at, but you can override those names.
• Use CREATED_AT and UPDATED_AT constants on the model.
• Make sure the actual table columns match the custom names.
• Do not disable timestamps unless you truly want no automatic timestamp management.
• Review the rest of the codebase for hard-coded references to the default column names.